---
# System prepended metadata

title: '#19.4 HTTP method 共同研究會 - POST/PUT'
tags: [Meetups]

---

---
title: "#19.4 HTTP method 共同研究會 - POST/PUT"
tags: Meetups
date: 2022-04-21
---

[4.3.3](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.3). POST

# 4.3.3 POST

  The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.  For example, POST is used for the following functions (among others):

根據資源獨有的語義（semantics），我們採用 representation 的資訊來處理請求中的目標資源

*   Providing a block of data, such as the fields entered into an HTML form, to a data-handling process
*   Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles
*   Creating a new resource that has yet to be identified by the origin server
*   Appending data to a resource's existing representation(s)

  An origin server indicates response semantics by choosing an appropriate status code depending on the result of processing the POST request; almost all of the status codes defined by this specification might be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).

來源伺服器會指定回應（response）的語意，如：來源伺服器根據 POST 請求處理的結果來選擇適當的 status code。

本規範所有的 status code，POST 的回應都有可能收到。除了 206、304、416

[304_Etag, If-None-Match](https://easonwang.gitbook.io/web_advance/liu-lan-qi-kuai-qu-yu-huan-cun)
[Nginx_Etag](http://nginx.org/en/docs/http/ngx_http_core_module.html#etag)

  If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).

假設一個或多個資源在來源伺服器裡成功創建的話，那來源伺服器**應該**要回應 201，並且包含提供主要資源的 identifier 的 Location header

  Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented.  For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).

  If the result of processing a POST would be equivalent to a representation of an existing resource, an origin server MAY redirect the user agent to that resource by sending a 303 (See Other) response with the existing resource's identifier in the Location field.  This has the benefits of providing the user agent a resource identifier and transferring the representation via a method more amenable to shared caching, though at the cost of an extra request if the user agent does not already have the representation cached.

如果 POST 處理後的結果，會等同於一個現存資源的 representation，來源伺服器**可以**傳送帶有已存在資源的 identifier 在 Location field 裡的 303 回應，來重新導向。

6.4.4.  303 See Other

   The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request.  A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request.  Note that the new URI in the Location header field is not considered equivalent to the effective request URI.

---

3.  Representations
    3.1. Representation Metadata
           3.1.1. Processing Representation Data
           3.1.2. Encoding for Compression or Integrity
           3.1.3. Audience Language
           3.1.4. Identification
      3.2. Representation Data
      3.3. Payload Semantics
      3.4. Content Negotiation
           3.4.1. Proactive Negotiation
           3.4.2. Reactive Negotiation

   Considering that a resource could be anything, and that the uniform
   interface provided by HTTP is similar to a window through which one
   can observe and act upon such a thing only through the communication
   of messages to some independent actor on the other side, an
   abstraction is needed to represent ("take the place of") the current
   or desired state of that thing in our communications.  That
   abstraction is called a representation [REST].

資源可以是任何東西，因為我們使用 HTTP 這個介面來傳輸這個資源，所以資源就會用 HTTP 的形式呈現。

   For the purposes of HTTP, a "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.

   An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a target resource.  In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on content negotiation.  This "selected representation" is used to provide the data and metadata for evaluating conditional requests [RFC7232] and constructing the payload for 200 (OK) and 304 (Not Modified) responses to GET (Section 4.3.1).
