path 파라미터, 쿼리스트링

if(confirm(`레알 ${name} 삭제?`)){

                    try{

                        await axios.delete(`http://localhost:3001/student/${id}`);

                    }catch(e){

                        console.error(e);

                            alert('삭제 과정 중 axios 통신 뒤짐')

                            return;

                           }

                    }

이런 코드가 있는데, 갑자기 궁금해진게,

http://localhost:3001/student/${id}

여기 이렇게 되어 있는 부분에, id 값이 들어가게 되는데, 이렇게 쓰는 방식을 패스 파라미터 방식이라고 하는게 맞는지,

그리고 저기 그냥 쿼리스트링 파라미터 방식으로

${id}대신 ?id=${id}를 집어넣으면 안되는지가 궁금해. 둘이 차이가 있고, 안되면 왜 안되는건지 말해줘

 

답안 표시

 

1. 패스 파라미터 방식이 맞는지?

네, 맞습니다. http://localhost:3001/student/${id}와 같이 URL 경로에 변수를 포함시키는 방식을 패스 파라미터(Path Parameter) 방식이라고 합니다. 이 방식은 RESTful API 설계에서 자원을 식별하고 특정 자원에 대한 작업을 수행할 때 주로 사용됩니다.

2. 쿼리스트링 파라미터 방식으로 변경 가능한지?

기술적으로는 ?id=${id}와 같이 쿼리스트링 파라미터 방식으로 변경하는 것이 가능합니다. 하지만, RESTful API 설계 원칙과 HTTP 메서드의 의미를 고려하면 DELETE 요청에는 쿼리스트링 파라미터 방식을 사용하지 않는 것이 좋습니다.

DELETE 요청과 쿼리스트링 파라미터

• DELETE 요청의 의미: DELETE 요청은 특정 자원을 삭제하기 위한 요청입니다.
• RESTful API 설계 원칙: RESTful API에서는 URL 경로를 통해 자원을 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 자원에 대한 작업을 수행합니다. 따라서, DELETE 요청은 삭제할 자원의 ID를 URL 경로에 포함시키는 것이 RESTful API 설계 원칙에 더 부합합니다.
• 쿼리스트링 파라미터의 역할: 쿼리스트링 파라미터는 주로 검색 조건, 필터링 옵션, 페이지네이션 정보 등 추가적인 정보를 전달하는 데 사용됩니다. 자원 자체를 식별하는 용도로는 적합하지 않습니다.
• 서버 측 구현: 서버 측에서 DELETE 요청을 처리할 때, 쿼리스트링 파라미터에서 ID를 추출하도록 구현되어 있지 않을 수 있습니다. 일반적으로 DELETE 요청은 URL 경로를 통해 ID를 전달하고, 서버 측에서는 경로 변수를 통해 ID를 추출하여 처리합니다.

결론

• DELETE 요청에는 패스 파라미터 방식을 사용하는 것이 RESTful API 설계 원칙에 더 부합합니다.
• 쿼리스트링 파라미터 방식으로 변경하는 것은 가능하지만, 서버 측 구현에 따라 문제가 발생할 수 있으며, RESTful API 설계 원칙에도 어긋납니다.
• 따라서, 가능하면 패스 파라미터 방식을 유지하고, 서버 측에서도 URL 경로를 통해 ID를 받도록 구현하는 것이 좋습니다.

참고: 쿼리스트링 파라미터 방식을 사용해야 하는 특별한 이유가 있거나, 서버 측에서 쿼리스트링 파라미터를 통해 ID를 처리하도록 구현되어 있다면 쿼리스트링 파라미터 방식을 사용할 수도 있습니다. 하지만 이는 일반적인 RESTful API 설계 방식과는 다르다는 점을 유의해야 합니다.