4. HTTP 메서드
API URI 설계
리소스를 식별하기 때문에 리소스 중심으로 작성
리소스와 해당 리소스를 대상으로 하는 행위를 분리
리소스: 회원
행위: 조회, 등록, 삭제, 변경
- GET 회원 목록 조회 /members
- GET 회원 조회 /members/{id}
- POST 회원 등록 /members/{id}
- POST 회원 수정 /members/{id}
- DELETE 회원 삭제 /members/{id}
HTTP 메서드 - GET, POST
-
GET:
리소스 조회, 전달할 데이터는 query를 통해서 전달
-
POST:
요청 데이터 처리, 주로 등록에 사용
메세지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터를 처리
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다
리소스 신규 등록, 프로세스 처리에 사용- 새 리소스 생성(등록)
• 서버가 아직 식별하지 않은 새 리소스 생성 - 요청 데이터 처리
• 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
• 예) 주문에서결제완료->배달시작->배달완료
처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
• 예) POST /orders/{orderId}/start-delivery (컨트롤 URI) - 다른 메서드로 처리하기 애매한 경우
• 예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
• 애매하면 POST
- 새 리소스 생성(등록)
-
PUT:
리소스를 대체, 해당 리소스가 없으면 생성(덮어씌우기)
클라이언트가 리소스를 식별한다
기존 내용이 사라질 수 있음 -
PATCH:
리소스 부분 변경
변경할 부분이 아닌 곳은 그대로 유지한다 -
DELETE:
리소스 삭제
HTTP 메서드의 속성
안전(Safe Methods)
호출해도 리소스를 변경하지 않는다멱등(Idempotent Methods)
몇 번 호출해도 결과가 같음
서버가 TIMEOUT 등으로 정상 응답을 못했을 때 자동 복구를 할 수 있는 판단 근거
멱등 메서드 : GET, PUT, DELETE캐시가능(Cacheable Methods)
응답 결과 리소스를 캐시해서 사용
캐시가능 메서드 : GET, HEAD, POST, PATCH (실제로는 GET, HEAD 정도만 캐시로 사용)
5. HTTP 메서드 활용
클라이언트에서 서버로 데이터 전송
데이터 전달 방식
-
쿼리 파라미터를 통한 데이터 전송
GET
주로 정렬 필터(검색어) -
메시지 바디를 통한 데이터 전송
POST, PUT, PATCH
회원 가입, 상품 주문, 리소스 등록, 리소스 변경
전달할 상황 4가지
- 정적 데이터 조회
- 이미지, 정적 텍스트 문서
- 조회는 GET 사용
- 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 조회
- 동적 데이터 조회
- 주로 검색, 게시판 목록에서 정렬 필터(검색어)
- 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
- 조회는 GET 사용
- GET은 쿼리 파라미터를 사용
- HTML Form을 통한 데이터 전송
- 회원가입, 상품주문, 데이터변경
- POST 전송, GET 전송
- Content-Type: application/x-www-form-urlencoded
- Content-Type: multipart/form-data
- HTTP API를 통한 데이터 전송
- 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)
- POST, PUT, PATCH 메세지 바디를 통해 데이터 전송
- Content-Type: application/json을 주로 사용
HTTP API 설계 예시
- HTTP API - 컬렉션
- POST 기반 등록
- 서버가 리소스 URI 결정
- HTTP API - 스토어
- PUT 기반 등록
- 클라이언트가 리소스 URI 결정
- HTML FORM 사용
- 순수 HTML + HTML form 사용
- GET, POST만 지원
