Http 파라미터 방식과 멱등성

Http 파라미터 받는 방식 정리

오늘 좀 어이없는 이슈가 있었는데 정리해보려고 한다.

1. 오늘 있었던 일

• 프론트에서 특정 post method api 가 500 에러가 뜬다는 이슈 발생
• swagger 에서 테스트해보니 너무 잘 동작함
• 즉 에러 재현이 안됨
• 프론트쪽에 request url 어떻게 보냈는지 여쭤 봄
• 프론트에서는 post method 이니 당연히 body data 로 파라미터를 보냄
• 그런데 그 api 는 query param 을 받는 post method api 였음
• 위 과정 약 1시간 반 소요..

2. 문제 분석

• path param, query param, body data 의 차이를 몰랐다
• POST 에서는 늘 body data 로 파라미터를 받아 왔는데, 이 API 만 Query Param 으로 받았다.
• 그렇게 개발한 이유가 있으면 (없음) 그걸 프론트에 충분히 고지해야 했다. (안함)
• 결정적으로 그걸 query param 으로 개발하고 있었다는 사실을 인지 못했다.

---

그럼 Query Param 과 Path Variable 은 뭐고, 어떻게 활용해야 하는가?

1. Query Param, Path Variable, Body Value

예를 들어 각각의 사용자를 위한 페이지를 만들려면 페이지 마다 식별된 파라미터 경로가 필요한데,

다음과 같은 get 파라미터를 사용할 수 있을 것이다.

/users?id=123  # 아이디가 123인 사용자를 가져온다.

하지만 데이터를 넘기는 방법 중의 하나로 Path Variable도 사용할 수 있다.

Path Variable은 다음과 같이 사용한다.

/users/123  # 아이디가 123인 사용자를 가져온다.

그리고 요청 body 에 데이터를 담아 보내는 방식도 있다.

서버 단에서는 보통 dto 로 정의해서 Request Body 를 받는다.

2. 그럼 각각을 언제 사용해야 하는가?

일단 여기서 중요한점은,

3가지 방식 모두 GET, POST, PUT, DELETE 모두 사용 가능하다.

그러나 각각 적절한 상황이 존재한다.

• 어떤 resource 를 식별하고 싶을 때는 Path Variable 을 사용한다.
• 정렬이나 필터링을 한다면 Query Parameter를 사용하는 것이 Best Practice 이다.
• Body 는 다음과 같은 경우에 사용한다.
  • 인수에 키-값 구조가 없는 경우
  • 직렬화 Binary 같이 사람이 읽을 수 없는 경우
  • 인수가 너무 많은 경우 (일부 서버는 URI 길이에 제한이 있음)

HTTP 메소드의 멱등성

멱등성이란, 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질을 말한다.

REST API 에서는 POST 를 빼고는 모두 멱등성이 보장 되어야만 한다.
즉 요청을 여러번 해도 늘 같은 동작을 하느냐를 기준으로 삼는 것이다.

다음 예를 보자.

어떤 데이터를 생성한다고 해보자.

  POST /data

POST 요청을 반복하면 데이터들은 계속 추가가 될 것이고, 서버는 매번 다른 응답을 뱉는다.
반면에 어떤 데이터를 조회한다고 해보자.

  GET /data

이 메소드를 여러번 호출 한다고 하더라도 서버의 상태가 변하지도 않고, 항상 같은 응답을 뱉는다.
따라서 위 메소드는 멱등성이 성립한다.

POST 메소드는 RESTful 에서는 멱등성이 보장되지 않는다.
따라서 call 자체가 안전해아 한다.

결론

• query param 은 외부에서 조작 될 여지가 있으므로, 비교적 안ㄴ전한 body data 를 권장한다.
• 그러나 query param 으로 바디가 적용 될 영역을 제한하는 역할로 사용 할 수도 있을 것이다.
• 하지만 내 경우에는 늘 body 형식으로 매개변수를 받다가 갑자기 방식을 바꿨으니 문제가 되었다.
• 따라서 개발자의 편의를 고려하는 방식을 사용하도록 하자.