1] POST

POST 메서드는 target resource가 리소스 자체의 특정한 의미에 따라 요청에 포함된 representation을 처리하도록 요청한다.

예를 들어, 다음의 기능을 수행한다.

1. HTML form에 입력된 필드같은 데이터 블록을 데이터 처리 프로세스에 제공

2. 게시판, 뉴스 그룹, 메일링 리스트, 블로그, 또는 비슷한 기사 그룹에 메시지 게시(posting)

3. origin server에서 식별되지 않은 새로운 리소스 생성

4. 리소스의 기존 표현에 데이터 추가(→ 기존 리소스에 데이터 추가)

origin server는 처리된 POST 요청의 결과에 따라 적절한 상태코드를 선택하여 response의 의미를 나타낸다.

RFC 9110에서 정의된 거의 모든 상태코드는 POST에 대한 응답으로 수신될 수 있다.
(예외적으로 206 Partial Content, 304 Not Modified, 416 Range Not Satisfiable은 안된다.)

만약 POST 요청의 성공적인 처리 결과로 origin server에서 1개 이상의 리소스가 생성된다면 origin server는 생성된 primary 리소스의 식별자를 제공하는 Location header field와 새로운 리소스를 참조하면서 요청의 상태를 설명하는 representation을(→ body에 새로운 리소스에 대한 정보를 준다.) 포함하여 201 CREATED 응답을 보내야한다.(should)

POST 요청의 응답은 explicit freshness information 및 POST의 target URI와 동일한 값을 갖는 Content-Location header field를 포함했을 때만 캐시할 수 있다.

캐시된 POST 응답은 후속 GET이나 HEAD 요청을 충족시키기 위해 사용할 수 있다.

이와는 반대로, POST는 잠재적으로 안전하지 않기 때문에 POST 요청은 캐시된 POST 응답으로 충족될 수 없다.

만약 기존에 있는 리소스의 representation과 POST 처리된 결과가 동일할 경우, rogin server는 Location field에 기존 리소스의 식별자가 포함된 303 See Other 응답을 전송하여 user agent(사용자)를 해당 리소스로 리디렉션 할 수 있다.(may)(→ 이미 생성했으므로 생성한 리소스로 이동한다.)

이것은 user agent에 리소스 식별자를 제공하고 shared caching(공유 캐시)에 더 적합한 방법을 통해 representation을 전송하는 장점이 있지만(303을 통해 클라이언트가 캐싱에 적합한 GET 메서드를 사용하도록 유도하므로) user agent에 이미 캐시된 representation이 없으면 추가 요청이 필요하다.