HTTP API URI를 설계할 때
가장 중요한 것은 리소스 식별이다.
-> 리소스를 URI에 매핑한다.
회원 관리 API 예시
회원 목록 조회 /members
회원 조회 /members/{id}
회원 등록 /members/{id}
회원 수정 /members/{id}
회원 삭제 /members/{id}참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어를 사용하는 것이 좋다고 한다.
그럼 위의 URI들을 어떻게 구분할까?
가장 중요한 것은 리소스를 식별하는 것이다.
URI는 리소스만 식별한다.
리소스는 명사, 행위는 동사
HTTP 메서드를 이용해서 API를 설정한다.
HTTP 메서드
GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제
GET
리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터)를 통해서 전달한다.
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다고 한다.
POST
요청 데이터를 처리
메시지 바디를 통해 서버로 요청 데이터 전달
서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
전달된 데이터는 주로 신규 리소스 등록, 프로세스 처리에 사용된다.
리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해놔야 한다. -> 정해진 것이 없음
다른 메서드로 처리하긴 애매한 경우 POST를 사용한다.
PUT
리소스를 대체
- 리소스가 있으면 대체
- 리소스가 없으면 생성
클라이언트가 리소스를 식별한다.
클라이언트가 리소스 위치를 알고 URI를 지정한다.
(POST와의 차이점이다)
PUT은 리소스를 완전히 대체한다
기존의 리소스는 사라짐
PATCH
리소스 부분 변경
동작 방식은 PUT과 비슷하나, 리소스가 다른 부분만 변경된다.
DELETE
리소스 제거
해당 URI의 리소스를 제거한다.
HTTP 메서드의 속성
안전, 멱등, 캐시가능
안전(Safe)
호출해도 리소스를 변경하지 않는다.
GET만 해당
안전은 해당 리소스만 고려, 로그는 고려하지 않음
멱등(Idempotent)
f(f(x)) = f(x)
한번 호출하든 두번 호출하든 결과가 똑같다.
GET, PUT, PATCH, DELETE가 해당
POST는 해당하지 않는다 - 계속 추가될 수 있음
멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.
캐시(Cacheable)
응답 결과 리소스를 캐시해서 사용해도 되는가?
GET, POST, PUT, PATCH 캐시가능
실제로는 GET 정도만 캐시로 사용한다.
