HTTP 메서드
URI 설계의 포인트 --> 리소스 식별
리소스 식별 방법
회원 등록, 수정, 삭제 기능을 구현할 시 회원이라는 개념 자체가 바로 리소스이다. 쉽게 말해서 회원이라는 리소스만 식별하면 된다.
ex)
회원 목록 조회 /members
회원 조회 /members/{id}
회원 등록 /members/{id}
회원 수정 /members/{id}
회원 삭제 /members/{id}
리소스와 행위를 분리(리소스는 명사, 행위는 명사)
HTTP 메서드 종류
GET:
-
리소스 조회
-
서버에 전달하고 싶은 데이터는 query를 통해서 전달
-
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
POST:
스펙: 대상 리소스가 리소스의 고유한 의미체계에 따라 요청에 포함된 표현을 처리하도록 요청한다.
-
요청 데이터 처리, 주로 등록에 사용하지만 프로세스의 상태만 변경이 되고 새로운 리소스가 생성되지 않을 수도 있음
ex) 주문에서 결제완료 -> 배달시작 -> 배달왼료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우 -
메시지 바디를 통해 서버로 요청 데이터 전달
-
다른 메서드로 처리 애매한 경우에 사용
ex) Json으로 조회데이터를 넘겨야하는데, GET 메서드를 사용하기 어려운 경우(애매하면 POST) -
주로 전달되 데이터로 신규 리소스 등록, 프로세스 처리에 사용
-
201 created로 응답, 자원의 location도 같이 응답
응답 데이터 ex)
http/1.1 201 created
Content-Type: application/json
Location: /members/100
{
"username": "young",
"age": 20
}PUT:
-
리소스를 대체, 해당 리소스가 없으면 생성 (덮어쓰기)
-
클라이언트가 리소스를 식별
클라이언트가 리소스의 위치를 알고 URI를 지정하는것이 POST와의 차이점이다.
ex) POST: /members PUT: /members/200
-
리소스를 완전히 대체한다
모든 리소스를 전부 덮어버린다. 리소스 수정보다는 덮어쓰기의 개념에 더 적합하다.
PATCH:
- 리소스 부분 변경(부분 수정 시에는 patch 사용)
DELETE:
- 리소스 삭제
HEAD:
- GET과 동일하지만 메시지 부분을 제외하고, 상태줄과 헤더만 반환
OPTIONS:
- 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT:
- 대상 자원으로 식별되는 서버에 대한 터널을 설정 (거의 사용하지 않음)
TRACE:
- 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 (거의 사용하지 않음)
HTTP 메서드의 속성
-
안전(safe)
- 호출해도 리소스를 변경하지 않는다
- 해당 메소드: GET, HEAD, OPTIONS, TRACE
-
멱등(Idempotent)
-
f(f(x)) = f(x)
-
한번 호출하든 두번 호출하든 100번 호출하든 결과가 같다.
-
해당 메소드: GET(조회 결과는 언제나 같다), PUT(결과를 대체 하기때문에 최종결과는 언제나 같다, DELETE(결과를 삭제한다. 삭제결과는 언제나 같다)
-
POST는 멱등이 아니다. 두번호출하면 같은 결제가 중복 발생할 수있다.
-
활용방법
- 자동 복구 메커니즘
- 서버가 timeout 등으로 정상 응답을 못주었을때, 클라이언트가 같은요청을 대도 되는가에 대한 판단 근거로 참고 가능
-
멱등은 외부 요인으로 중간에 리소스가 변경되는것까지는 고려하지 않는다.
-
-
캐시가능(Cacheable)
- 응답결과 리소스를 캐시로 사용
- GET, HEAD, POST, PATCH 캐시가능
- 실제로는 GET, HEAD 정도만 캐시로 사용하고, POST, PATCH는 본문 내용까지 캐시키로 고려해야하여, 구현이 쉽지 않다.
