HTTP 요청 메서드
-
요청 메서드를 정의하여 주어진 리소스에 수행하길 원하는 행동을 나타냄
-
각각의 메서드는 서로 다른 의미를 가지며 일부 기능은 메서드 집합 간에 서로 공유하기도 함
-
응답 메서드는 안전하거나, 캐시 가능하거나, 멱등성을 가질 수 있음
| 요청 메서드 | 설명 |
|---|---|
GET | 특정 리소스의 표시를 요청하며 GET을 사용하는 요청은 데이터만 받음 |
HEAD | GET 메서드와 동일한 응답을 요구하지만, 응답 본문을 포함하지 않음 |
POST | 특정 리소스에 엔티티를 제출할 때 사용하며 이것은 종종 서버의 상태의 변화나 부작용을 유발 |
PUT | 목적 리소스 모든 현재 표시를 요청 payload로 변경 |
DELETE | 특정 리소스를 삭제 |
CONNECT | 목적 리소스로 식별되는 서버로 터널을 연결 |
OPTIONS | 목적 리소스의 통신 설정에 사용 |
TRACE (en-US) | 목적 리소스의 경로를 따라 메시지 loop-back 테스트 |
PATCH | 리소스의 부분을 수정하는데 사용 |
안전함
-
HTTP 메서드가 서버의 상태를 바꾸지 않는 것
-
읽기만을 수행하는 메서드는 안전하며 대표적으로
GET,HEAD,OPTIONS가 있음 -
모든 안전한 메서드는 멱등성 또한 갖지만, 모든 멱등성을 지닌 메서드가 안전하지는 않음
PUT,DELETE
캐시 가능 Cacheable
-
캐시할 수 있는 HTTP 응답
-
나중에 검색하고 사용하기 위해 저장하여 새 요청을 서버에 저장
-
모든 HTTP 응답이 캐시할 수 있지 않음
-
캐시 가능한 제약 조건
-
GET,HEAD메서드는 요청에 사용된 메서드는 그 자체로 캐시 가능GET /pageX.html HTTP/1.1 (...) 200 OK (...) -
PUT요청은 캐시 할 수 없으며 같은 URI에 대한HEAD,GET을 통한 요청은 캐시된 데이터를 무효화PUT /pageX.html HTTP/1.1 (…) 200 OK (…) -
애플리케이션 캐싱에 의해 알려진 응답의 상태 코드는 캐시 가능한 것으로 간주
200,203 (en-US),204,206,300,301,404,405,410,414,501상태 코드
-
응답에는 Cache-control과 같은 캐싱을 방지하는 특정 헤더가 존재
(…) 200 OK Cache-Control: no-cache (…)
-
멱등성
-
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가진다고 말함
-
통계 기록 등을 제외하면 어떠한 부수 효과도 존재해서는 안된다.
-
GET,HEAD,PUT,DELETE메서드는 멱등성을 가짐 -
첫
DELETE요청이200을 반환한다면, 그 이후에는 아마404를 반환할 것이며DELETE가 멱등성을 가진다는 것은, REST API에서 개발자가DELETE를 사용하여 목록의 마지막 항목 제거 기능을 구현해서는 안된다는 것을 의미 -
멱등성 예제
- GET /pageX HTTP/1.1를 여러 번 연속해서 호출해도 클라이언트가 받는 응답은 동일
GET /pageX HTTP/1.1 GET /pageX HTTP/1.1 GET /pageX HTTP/1.1 - POST /add_row HTTP/1.1는 멱등성을 갖지 않음. 여러 번 호출할 경우, 여러 열을 추가
POST /add_row HTTP/1.1 POST /add_row HTTP/1.1 -> Adds a 2nd row POST /add_row HTTP/1.1 -> Adds a 3rd row - DELETE /idX/delete HTTP/1.1의 상태 코드는 응답마다 달라질 수 있지만, 그럼에도 멱등성을 가짐
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted DELETE /idX/delete HTTP/1.1 -> Returns 404
- GET /pageX HTTP/1.1를 여러 번 연속해서 호출해도 클라이언트가 받는 응답은 동일
