[Http] Http 메소드

http API 설계

API URI 설계

uri 설계에서 가장 중요한 것은 리소스 식별!

 

리소스란?
회원을 등록하고 수정하고 조회하는 게 리소스가 아니다.
회원이라는 개념 자체가 리소스다.

 

리소스 식별

회원을 등록하고 수정, 조회하는 것을 모두 배제하고 회원이라는 리소스만 식별하면 된다. 

-> 회원이라는 리소스를 uri에 매핑

 

ex) read-member-by-id
-> /members/{id}  (조회)
/members/{id}  (등록)
/members/{id}  (삭제)...
계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장

 

URI는 리소스만 식별
리소스와 해당 리소스를 대상으로 하는 행위를 분리
리소스(명사): 회원
행위(동사): 조회, 등록, 삭제, 변경...
행위(메소드)는 http 메소드로 구분

 

---

 

http 메소드 (GET, POST)

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

 

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query를 통해서 전달
• 메시지 바디를 통해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

 

POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

 

---

 

http 메소드 (PUT, PATCH, DELETE)

 

PUT

• 리소스를 대체
  리소스가 있으면 대체
  리소스가 없으면 생성
• 클라이언트가 리소스를 식별
  클라이언트가 리소스 위치를 알고 URI 지정 (POST와 차이점) -> post는 uri에 회원 id를 적지 않지만 post는 클라이언트가 uri에 id를 지정   ex) /members/101
  

 

PATCH

• 리소스 부분 변경
  ex) 회원의 여러 정보 중 특정 정보(예를 들어 휴대폰 번호)만 변경하고 싶을 때 변경할 휴대폰 번호만 담아서 보내면 해당 정보만 변경이 되고 나머지 정보는 유지된다. -> PUT과 차이점(PUT은 휴대폰 번호만 보냈을 경우 휴대폰 번호 정보만 남고 나머지 데이터는 삭제된다)

 

DELETE

• 리소스 제거

 

---

 

http 기타 메소드

http 기타 메소드

주로 head, options 정도만 사용

 

 

---

 

http 메서드의 속성

• 안전(Safe)
• 멱등(Idempotent)
• 캐시 가능(Cacheable)

 

 

안전(Safe)

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

 

멱등(Idempotent)

• 한 번 호출하든 100번 호출하든 결과가 똑같은 것
• 활용
  자동 복구 메커니즘
  서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거
  -> 멱등하다면(다시 호출해도 결과가 같다면) 다시 호출해도 문제가 생기지 않음
• 멱등은 외부 요인으로 리소스가 변경됐을 경우까지는 고려하지 않는다.
  ex) 100번 회원을 get 했는데 중간에 누군가 put 해서 회원 정보가 변경된 경우 -> 멱등에 해당 X

 

 

캐시 가능(Cacheable)

• 응답 결과 리소스를 캐시 해서 사용해도 되는가
• GET, HEAD, POST, PATCH는 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용
  POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음