HTTP API
HTTP API 설계에서 가장 중요한 것은 리소스 식별과 리소스-행위의 분리이다.
리소스만 가지고 설계할 수 없는건 컨트롤URI로 설계한다.
- 리소스 : API의 수행 대상
- 행위 : 서버->클라이언트 요청할 때 기대하는 행동
- 리소스 URI : 동사 의미가 포함된 URI
ex) POST /orders/{orderId}/start-delivery
HTTP 메서드
GET : 리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
POST : 요청 데이터 처리, 주로 등록에 사용
스펙 : 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청
메시지 바디에 요청 데이터를 담아 서버에 처리해달라고 요청
- 새 리소스 생성,등록
- 요청 데이터 처리 (프로세스의 상태 변경)
- 다른 메서드로 처리하기 애매한 경우
- location : 자원이 생성된 경로
PUT : 해당 리소스가 없으면 생성, 있으면 대체
POST와 차이점은 클라이언트가 소스 위치를 알고 URI를 지정한다는 것
- 리소스 있을 때
- 만약, 클라이언트에서 {"age":50}를 PUT으로 보내면 서버의 리소스에서 username 필드는 삭제되고 {"age":50}으로 업데이트 된다. PUT은 수정보단 대체 개념으로 봐야한다.
- 리소스 없을 때
PATCH : 리소스 부분 변경
DELETE : 리소스 삭제
기타
HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정 (거의 사용X)
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 (거의 사용X)
HTTP 메서드의 속성
안전 (Safe Methods)
호출해도 리소스를 변경하지 않는다.
ex) GET
멱등 (Idempotent)
- 서버가 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지 판단 근거가 된다.
- 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.
ex) GET->PUT->GET하면 데이터가 바뀔 수 있지만 이는 멱등 고려 상황이 아니다. - 멱등 O : GET, PUT, DELETE
멱등 X : POST - 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
캐시가능 (Cacheable)
응답 결과 리소스를 캐시해서 사용해도 되는가?
GET, HEAD, POST, PATCH 캐시 가능
실제로는 GET, HEAD 정도만 캐시로 사용
POST, PATCH는 본문 내용까지 캐시 키로 고려해야해서 구현이 쉽지 않음
인프런 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의를 기반으로 작성했습니다.
