PUT VS POST
서비스 개발 도중 문득 put 과 post의 차이가 분명하지 않아 직접 찾아본 자료들을 정리해둔 글이다.
HTTP API 개발 단계에서 서버 자원을 수정, 추가, 배포하기 위해서는 어떤 메서드를 사용해야 하나? 네트워크 지식이 매우 미흡한 작성자에게는 상당히
어려운 부분이다. 간단한게 말해서 하나도 모른다.
그렇다고 HTTP의 정의부터 전부 쓰기도 그러니 공식 문서(rfc7231)를 참고하여 중요한 토픽 위주로 먼저 정리하려 한다.
Common Method Properties
Safe Methods
- 사용자의
GET,HEAD,OPTIONS같은 요청으로 인한 side-effects는 사용자에게 책임을 물을 수 없다. - 이를 통해 다른 메서드의 경우에 위험 가능성을 명시한다.
- 읽기 전용인 경우 안전한 메서드로 간주한다.
Idempotent Methods
우리말로는 멱등성(?)이라는 단어를 사용하던데 상당히 생소하다.
- 서버 통신 장애로 인해 요청이 반복될 수 있어
Idempotent Methods는 구분된다, - 여러 번의 요청과 한 번의 요청의 결과가 동일하다면
Idempotent하다. PUT,DELETE와Safe Method가 여기에 속한다.
Cacheable Methods
요청 메서드는 이후 재사용 가능성에 의해 cacheable 할 수 있다.
- 일반적으로 권한 요청이 없거나, 현재에 의존성이 없는
safe method는cacheable하다 GET,HEAD,POST는cacheable하다.
Method Definitions
POST
- HTML 폼에 입력된 필드를 받아 데이터 핸들링을 할 경우
- 게시판, 블로그 등의 포스팅
- 서버의 새로운 데이터 쓰기
- 데이터 추가
POST 요청에 대한 응답 status code는 대부분 being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)로 정의된다.
새로운 리소스가 서버에 생성되었다면, 201 (Created)를 생성된 리소스에 대한 설명과 식별자를 함께 보낸다.
POST는 freshness 정보가 정확히 명시되었을 때 cacheable하다.
| 요청에 바디 존재 | O |
| 성공 응답에 바디 존재 | O |
| 안전성 | X |
| 멱등성 | X |
| 캐시 가능 |
PUT
- 기존 리소스를 대체하거나 새로 생성하는 요청을 주로한다.
- 서버는 변환없는 저장, 새로운 데이터를 반영하지 않을 경우 절대로
ETag,Last-Modified같은alidator header field를 보내선 안된다. 이 요건은 사용자 에이전트가 PUT의 결과로 메모리에 있는 바디가 최신 상태를 유지할 때 알 수 있도록 하므로 서버에서 다시 검색할 필요가 없으며, 응답에서 받은 새로운validator에 우발적인 덮어쓰기를 방지하기 위해 미래의 조건부 요청에 사용할 수 있다.
타켓 리소스와 다를 경우 PUT 메서드는 요청을 적절한 형태의 에러코드를 발생할 수 있다. 이 때 409 (Conflict), 415 (Unsupported Media Type) 상태코드를 보낸다. 생성할 경우 201 (Created)를, 수정할 경우는 요청이 완료되었다는 의미로 200 (OK)이나 204 (No cotent) 상태 코드를 보낸다.
| 요청에 바디 존재 | O |
| 성공 응답에 바디 존재 | X |
| 안전성 | X |
| 멱등성 | O |
| 캐시 가능 | X |
PUT or POST?
그렇다면 둘의 차이점은 도대체 무엇일까? 공식문서에서는 아래와 같이 설명하고 있다.
The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource’s own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
간단히 말하자면 idempotent에서 차이가 있다.
- POST 같은 경우 여러번의 요청이 있을 경우, 연속적인 시퀀스라 인지하여 추가적인 영향이 있을 수 있다.
- PUT 같은 경우 리소스를 대체하거나 새로 생성하지만
idempotent에 의해 요청수에 상관없이 결과는 같다.
Refernce
- https://tools.ietf.org/html/rfc7231#section-4.1
- https://feel5ny.github.io/2019/08/16/HTTP_003_02/
- https://ko.wikipedia.org/wiki/HTTP