API URI 설계할 때는 메소드를 제외하고 리소스만 식별하는 것이 바람직한 설계지만,
리소스만 구분하면 수많은 기능을 구현할 때 한계에 부딪힌다.
그래서 리소스와 행위를 분리하여 만드는 것이 가장 바람직하다.
URI는 리소스만 식별!
리소스와 해당 리소스를 대상으로 하는 행위을 분리하여 설계
GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제
리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지
않음
동작 순서
요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터를 처리
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
동작 순서
POST 정리
리소스를 대체
중요! 클라이언트가 리소스를 식별
동작 방식
리소스가 있는 경우 클라이언트가 PUT 요청을 하면
서버에서는 기존의 리소스를 대체한다.
만약 이렇게 리소스가 없는 상태에서 클라이언트가 PUT 요청을 하면
서버에서는 신규 리소스를 생성해서 만든다.
한가지 주의할 점은 이렇게 리소스 일부만을 PUT했을 때,
리소스는 완전히 대체하기 때문에 기존에 리소스가 있었더라도 일부분만 수정되늑네 아니라 완전히 대체된다.
리소스 부분 변경
리소스 제거
안전(Safe Methods)
멱등(Idempotent Methods)
캐시가능(Cacheable Methods)
호출해도 리소스를 변경하지 않는다.
Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면요?
A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다.
한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
멱등 메서드
활용
- 자동 복구 메커니즘
- 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해
도 되는가? 판단 근거
Q: 재요청 중간에 다른 곳에서 리소스를 변경해버리면?
A: 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.
응답 결과 리소스를 캐시해서 사용해도 되는가?
GET, HEAD, POST, PATCH 캐시가능
실제로는 GET, HEAD 정도만 캐시로 사용