API URI 설계에서 가장 중요한것은 리소스 식별이다. 즉 리소스를 대상으로 하는 행위를 분리시킨다.
예) 회원 수정 -> 회원이 리소스
-> HTTP 메서드
주요 메서드
주로 리소스 조회를 할떄 사용되며 서버에 전달 하고싶은 데이터는 query(쿼리 파라미터,쿼리 스트링) 을 통해서 전달한다.
메시지 바디를 사용할수 있지만 지원하지 않는 곳이 많아서 사용하지 않는걸 추천
메시지 바디를 통해 서버로 요청 데이터 전달(서버로 데이터를 보내 처리요청)
서버는 요청 데이터를 처리
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행 (주로 신규 리소스 등록, 프로세스처리)
->이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 -> 정해진 것이 없음
• 리소스를 대체
• 리소스가 있으면 대체
• 리소스가 없으면 생성
• 쉽게 이야기해서 덮어버림 = 리소스를 완전히 대체한다
• 중요! 클라이언트가 리소스를 식별
• 클라이언트가 리소스 위치를 알고 URI 지정
• POST와 차이점
• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)
• 호출해도 리소스를 변경하지 않는다
한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다
멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다 예) GET -> PUT -> GET X
내가 동일한 요청을 똑같이 요청했을떄
- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
- POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
delete를 보냈는데 서버가 응답이 없을떄 클라이언트가 같은 요청을 다시해도 되는지 판단근거(멱등 하기 떄문에, 한번 or 100번 호출하든 결과 똑같)
자동 복구 매커니즘
• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시가능
• 실제로는 GET, HEAD 정도만 캐시로 사용
• POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음