HTTP 메서드

URI 설계

URI는 리소스만 표현하도록 설계하는 것이 좋다. 아래의 회원 목록을 조회하는 API URI를 보자

/read-memeber-list

URI를 보면 리소스에 대한 행위를 나타내는 read와 리소스를 나타내는 member-list가 있는 것을 볼 수 있다. 하지만 HTTP에서 리소스에 대한 행위는 HTTP 메서드로 표현한다. 때문에 URI는 오직 리소스만 표현하며 리소스에 대한 행위는 메서드로 지정하는 것이 더 좋은 URI 설계 방법이다. 이 밖에도 더 좋은 URI를 설계하기 위한 여러가지 지침들이 있다. (반드시 지켜야 되는 건 아니다.)

 

회원 목록을 조회하고 회원 조회, 등록, 수정, 삭제하는 API URI는 아래와 같이 설계할 수 있다.

(회원목록조회 URI) /members
(회원조회 URI) /member/{id}
(회원등록 URI) /member/{id}
(회원수정 URI) /member/{id}
(회원삭제 URI) /member/{id}

HTTP 메서드

GET

GET 메서드는 리소스의 표현 중 현재 선택된 표현의 전송을 요청한다.

• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메세지 바디에 데이터를 넣어 전달할 순 있지만, 지원하지 않는 곳이 많아 권장하지 않음

 

POST

POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청

• 메세지 바디를 통해 서버로 요청 데이터(요청에 포함된 표현) 전달하고 서버는 요청 데이터 처리
• 주로 전달된 데이터로 신규 리소스를 등록하거나 프로세스 처리에 사용
• POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야함 → 정해진 것이 없음(POST로 다 가능)

 

주요 POST의 사용 예

• 신규 리소스 등록
• 요청 데이터 처리
  • 단순한 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
  • 예) 결제 완료  → 배달 시작 → 배달 완료 처럼 단순 값 변경을 넘어 프로세스의 상태가 변경되는 경우
  • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
  • POST /orders/{orderId}/stat-delivery (컨트롤 URI)
• 다른 메서드로 처리하기 애매한 경우
  • 메세지 바디에 JSON을 넣어 리소스를 요청하고 싶은데, GET으로 하기 애매함(보통 GET은 메세지바디 허용 X)
  • 애매하면 POST

 

PUT

PUT 메서드는 리소스를 대체한다.

• 리소스 대체
  • 리소스가 있으면 대체 (덮어버림)
  • 리소스가 없으면 생성
• 클라이언트가 리소스의 식별자(URI)를 알고 있어야함
  • 클라이언트가 리소스의 URI 지정
  • POST와의 차이점

POST로도 리소스를 대체할 수 있지만 PUT와의 차이점은 PUT 사용시 클라이언트가 리소스의 URI를 지정한다는 점이다. 신규 리소스 생성을 요청하는 POST 메세지와 PUT 메세지를 비교해보자.

POST VS PUT

POST 메세지는 members 리소스에 신규 리소스 등록을 요청하고 있다. 서버는 이 요청을 받아들여 리소스를 생성하고 리소스의 URI를 서버 측에서 정한다. /members/100 일수도 있으며 /members/200 일수도 있다. 반면에 PUT 메세지는 리소스의 URI가 지정되어 있다. 서버는 이 요청을 받아들여 리소스를 생성하고 리소스의 URI를 /members/100로 정한다.

 

PATCH

PATCH 메서드는 리소스를 부분적으로 변경한다.

 

DELETE

DELETE 메서드는 리소스를 제거한다.

HTTP 메서드의 속성

HTTP 메서드의 속성으로 안전(Safe Methods), 멱등(Idempotent Methods), 캐시가능(Cacheable Methods)이 있다.

안전

• 호출해도 리소스가 변경되지 않는다.

 

멱등

• 한번 호출하든 여러번 연속으로 호출하든 결과가 똑같다.
• f(x) = f(f(x))
• 멱등 메서드
  • GET : 여러 번 호출해도 같은 리소스가 조회된다.
  • PUT : 리소스를 대체한다. 여러 번 호출해도 최종 결과를 같다.
  • DELETE : 리소스를 삭제한다. 여러 번 호출해도 삭제된 결과는 같다.
  • POST : 멱등이 아니다! 여러 번 호출할 시 문제가 발생할 수 있다. (중복 결제 등)
• 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지 고려하지 않는다.

 

캐시 가능

• 응답 결과 리소스를 캐시해 재사용해도 되는 메서드는 캐시 가능하다고 말한다.
• GET, HEAD, POST, PATCH가 캐시 가능하지만 실제로는 GET, HEAD 정도만 캐시를 사용한다.
• POST, PATCH는 바디 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.