🔎 URI 설계
- URI는 Resource식별
📌 Resource와 행위를 분리
- URI는 Resource
- Resource와 해당 Resource 대상으로 하는 행위를 분리
- Resource: 행위
- 행위(Method): 조회, 등록, 삭제, 변경
- Resource는 명사, 행위는 동사
📌 HTTP 메서드 종류
- GET: 리소스 조회
- POST: 요청 데이터 처리, 주로 등록에 사용
- PUT: 리소스를 대체, 해당 리소스가 없으면 생성 (덮어쓰기)
- PATCH: 리소스 부분 변경
- DELTE: 리소그 삭제
기타 메서드
- HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
- OPTIONS: 대상 리소스에 대한 통신 기능 옵션(메서드)를 설명(주로 CORS에서 사용)
- CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프팩 테스트를 수행
💡 GET
💡 POST
- 새 리소스 생성(등록)
- 요청 데이터 처리
- 단순히 데이터를 생성하거나, 변경하는 것을 넘어 프로세스를 처리해야 하는 경우
- 데이터를 받아서 처리하지 않더라도, 서버 혹은 데이터베이스 상태에 변경과 같은 프로세스를 처리할 때
- 그 결과물로 새로운 리소스가 생성되지 않을 수도 있다.
- ex) POST /orders/{orderId}/start-delivery (컨트롤 URI)
(동사로 URI가 설정되어 프로세스 처리에 활용)
💡 PUT
- 리소스를 완전히 대체버린다.
💡 PATCH
💡 DELETE
🔎 HTTP 메서드의 속성
- 안전(Safe Methods)
- 멱등(Idepotent Methods)
- 캐시가능(Cacheable Methods)
📌 안전
- 호출해도 리소스를 변경하지 않는다
📌 멱등 (Idempotent)
- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 같다.
- 멱등 메서드
- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회
- PUT: 결과를 대체한다(덮어쓴다). 따라서 같은 요청을 여러번 하더라도 최종 결과는 항상 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 값다.
- POST: 호출 횟수가 서버 상태에 변화를 불러일으켜 여러 번 호출 시 에러 응답값이 올 수 있다.
(ex. 결제를 두 번한다)
-> 몇 번을 호출하든 같은 결과 응답값이 주어지느 경우를 멱등(Idepotent)하다고 표현한다.
📌 캐시가능
- GET, HEAD, POST, PATCGH 캐시 가능
- 실제로는 GET, HEAD 정도만 캐시 사용
- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하기 때문에 구현이 쉽지 않음
