[http] http 메소드, 메소드 속성

HTTP API를 잘 만들기 위해서는?

• API URI을 잘 만들어야 함.
• 리소스를 잘 식별해야 함.
  • 리소스를 식별하기 위해서는?
  • 리소스 (ex. 회원, 주문정보, ...)
• 리소스를 식별하고 나서는? 리소스에 대한 어떤 액션을 해야 하는가?
• 액션을 http 메소드로 구분하기
• 리소스는 명사, 행위는 동사

 

http 메소드

• get
• post
• put
• patch
• delete
• head
• options — cors에서 사용
• connect
• 기타 등등

 

GET

• 쿼리 파라미터, 쿼리스트링을 통해 조회
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만 지원하지 않는 곳이 많아 권장하지 않음

 

POST

• 리소스에 대한 저장, 처리를 요청
• 대상 리소스가 리소스 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청?
• 단순 데이터 생성, 변경이 아니라 프로세스를 처리해야 하는 경우
• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
• 예) POST /orders/{orderId}/start-delivery (컨트롤 URI)

 

PUT

• 리소스를 완전히 대체
• 중요!
  • 클라이언트가 리소스를 식별
• 기존 데이터를 통째로 지우고 올려버림
  • username, age가 있는 데이터를 변경한다하면
  • age만 요청값에 넘기면 기존에 username이 있다면 없어지고 age만 들어감
  • 부분 변경을 하고 싶은데? -> PATCH를 사용해야 함.

 

PATCH

• 부분 변경을 하고 싶은 경우에 사용
• ex) age만 변경하고 싶을때

 

DELETE

• 삭제

 

HTTP 메소드의 속성

안전

• 호출해도 리소스를 변경하지 않는다.
  • 안전이 보장되는건 해당 리소스만 고려한다.

멱등

• idempotent
• 한번 호출하든 두번 호출하든 100번 호출하든 결과가 똑같다.
• 멱등 메서드
  • get : 한번 조회하든, 두 번 조회하든 같은 결과
  • put : 결과를 대체. 같은 요청을 여러번 해도 최종 결과는 같다.
  • delete : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같음
  • post : 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생 가능
• 멱등성 활용 
  • 자동 복구 매커니즘
  • ex) delete를 요청하고 문제가 생겨서 실패했다면 다시 요청하는게 가능.
• 멱등이라고 했는데 아닌 경우가 있지 않나요?
  • get → put(변경됨.) → get(변경된 것을 조회)
  • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.

 

캐시 가능

• 응답 결과 리소스를 캐시해서 사용해도 되나?
• get, head, post, patch 캐시 가능
• 실제로는 get, head 정도만 캐시로 사용
  • 다른 메소드는 요청 바디까지 캐시 키로 고려해야 돼서 쉽지 않음

---

내용 출처

• 모든 개발자를 위한 http 웹 기본 지식