HTTP API 설계 예시(모든 개발자를 위한 HTTP 기본 지식,Feat PATCH vs PUT vs POST)

강의 4:50

[수정] API의 HTTP 메서드는 되도록이면 PATCH를 사용

PUT의 경우 기존 리소스를 아예 덮어 버리기 때문에 리소스의 항목 중 일부 항목에 대한 수정 정보를 넣지 않게 되면

그 항목이 전부 날라가게 된다. 

그러나 수정 중에서도 일부 수정이 아니라 전체 수정을 하는 경우에는 PUT을 사용하는 것이 더 적합

예를 들어, 게시글 같은 경우에는 부분 수정이 아니라 대부분의 경우 전체 수정이기 때문이다. 

PATCH와 PUT 둘다 사용하기에는 애매한 상황에서는 POST를 사용!!

 

PUT 등록과 POST 등록의 차이(강의 5분 55초)

회원 등록 : /members -> POST

-> 클라이언트는 회원의 리소스 위치를 모르고, 서버에서 회원 리소스를 등록하고 그 위치를 서버에서 생성

회원 등록 : /members/100 ->PUT

-> 클라이언트는 반드시 회원의 리소스 위치를 알아야 한다. 해당 리소스 위치에 회원 리소스가 없으면 새로 생성하고

있으면 덮어 쓰기를 한다.(PUT을 사용한다는 것은 클라이언트 개발자가 리소스의 URI를 다 알고 있으며, 리소스를 관리한다는 뜻! POST는 클라이언트가 리소스를 관리 X -> 서버가 리소스를 관리)

* PUT을 사용하는 비중은 매우 적다! 대부분 POST로 해결!

 

컬렉션(Collection) vs 스토어(Store)

컬렉션 : 서버가 리소스를 관리하는 디렉터리

ex) 회원 등록 : /members -> POST : [/member]라는 컬렉션에서 서버가 회원 리소스를 관리

스토어 : 클라이언트가 관리하는 리소스 저장소

ex) 파일 등록 : /files/star.jpg -> PUT : [/files]라는 스토에서 클라이언트가 파일 리소스를 관리

 

HTML Form을 이용한 데이터 전송

기본적으로 GET,POST 이 두 개밖에 지원을 하지 않는다. 

만약 PUT,DELETE,PATCH와 같은 메서드를 사용하려고 하면 HTML 기능 없이 순수 자바스크립트 만으로 통신(AJAX)을 

통하여 API를 요청하고 응답 받아야 한다. 

 

HTTP API의 URL 설계 기준(강의 27:00)

1. 무조건 리소스를 기반으로 URL을 계층적으로 설계

2. 리소스를 대상으로 하는 행위는 HTTP METHOD를 사용

3. 위 1~2를 가지고 URL이 설계가 잘 안 될 떄에는 컨트롤 URL를 사용!!

->예를 들어서 "주문 시작 -> 배송 중 -> 배송 완료"와 같은 추가 프로세스 실행을 하는 API 같은 경우에는

/orders/{주문 번호} -> PUT, /orders/{주문 번호} -> POST 중 어느 URL로 하여도 URL만 보고는 무슨 API인지 알기가 어렵

렵다. 이러한 경우에는 동사를 이용한 컨트롤 URL을 사용하면 된다. 

EX) /orders/{주문번호}/deliver : 컨트롤 URL