HTTP 메서드

HTTP API 설계

---

요구사항

회원 정보 관리 API

• 회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제

API URI 설계 방법

 

URI를 설계할 때 가장 중요한 것은, 리소스 식별이다.

• 리소스 : 행위의 주체가 되는 객체
• 회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제 → 리소스 : 회원

• 행위는 HTTP 메서드를 통해 구분
  • 즉, 리소스와 해당 리소스를 대상으로 하는 행위를 분리
    • 리소스 : 회원 → URI
    • 행위 : 조회, 등록, 삭제, 변경 → HTTP 메서드

HTTP 메서드 - GET, POST

---

HTTP 메서드 종류

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스의 부분 변경
• DELETE : 리소스 삭제

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query를 통해 전달
• 메세지 바디를 사용해 데이터 전달은 가능 → 지원하지 않는 서버가 많아 권장 X

POST

• 요청 데이터 처리
  • URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지는 리소스마다 따로 정하는 것
• 메세지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리 등에 사용

POST 정리

• 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우에도 POST를 사용할 수 있다.
• POST의 결과로 새로운 리소스가 생성되지 않을 수 있다.
• 컨트롤 URI에서 사용될 수 있다.
  • 컨트롤 URI : URI에서 동사를 사용 ex) /orders/{orderId}/start-delivery
• 다른 메서드로 처리하기 애매한 경우도 사용될 수 있다.
  • 데이터를 조회해야 할 때 JSON 데이터를 전달해야 할 때
    • 그래도 조회할 때는 GET을 사용하는 것이 일반적으로 좋다(caching 등..)

PUT, PATCH, DELETE

---

PUT

PUT /members/100 HTTP/1.1
Content-Type: application/json

{
	"username": "old",
	"age": 50
}

• 리소스를 완전히 대체
  • 기존 리소스를 완전히 삭제하고, 대체한다 → 일부 수정이 안 됌
• 클라이언트가 어떠한 리소스를 생성하고, 대체할 것인지를 알고 있다.
  • PUT members/100 → 100번 리소스를 생성 및 대체할 것을 알고 있다.
  • POST와의 차이점

PATCH

• 리소스의 부분 변경
• 서버에서 PATCH를 지원하지 않는 경우에는 POST를 사용!

DELETE

• 리소스 제거

HTTP 메서드의 속성

---

메서드 속성 : 안전, 멱등, 캐시 가능

안전

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

멱등

• f(f(…f(x)…) = f(x) → 여러번 호출해도 결과가 동일한 경우
• GET : 여러번 조회해도 결과는 동일
• PUT : 결과를 대체하기 때문에 여러번 PUT해도 리소스는 동일
• DELETE : 여러번 삭제해도 리소스가 삭제된 상태는 동일
• POST : 멱등 X
  • 리소스 등록 같은 경우에는 멱등할 수도 있지만, 컨트롤 URI 등을 수행할 때에는 그 결과가 달라질 수 있다.
  • /order/{orderId}/start-delivery를 여러번 호출하면, 배달이 여러번 수행될 수 있음

멱등이 필요한 이유

• 자동 복구 매커니즘을 위함
• 서버가 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 또 해도 되는지 안 되는지를 판단할 수 있다.

예외 사항

• 외부 요인으로 인해 중간에 리소스가 변경되는 경우는 고려하지 않는다.

캐시가능

• 응답 결과 리소스를 캐시해서 사용해도 되는 경우
• GET, HEAD, POST, PATCH → 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시
• GET, HEAD 같은 경우는 URL 자체를 key로 해서 결과를 cahcing하면 되기 때문에 간편
• POST, PATCH 등은 본문 내용까지 key로 해서 결과를 caching해야 하기 때문에 구현이 어렵다.