問題描述
POST 和 PUT HTTP 請求有什麼區別？ (What's the difference between a POST and a PUT HTTP REQUEST?)
它們似乎都是在body內部向服務器發送數據，那麼它們有什麼不同呢？
參考解法
方法 1:
HTTP PUT:
PUT puts a file or resource at a specific URI, and exactly at that URI. If there's already a file or resource at that URI, PUT replaces that file or resource. If there is no file or resource there, PUT creates one. PUT is idempotent, but paradoxically PUT responses are not cacheable.
HTTP POST:
POST sends data to a specific URI and expects the resource at that URI to handle the request. The web server at this point can determine what to do with the data in the context of the specified resource. The POST method is not idempotent, however POST responses are cacheable so long as the server sets the appropriate Cache‑Control and Expires headers.
The official HTTP RFC specifies POST to be:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
- Providing a block of data, such as the result of submitting a form, to a data‑handling process;
- Extending a database through an append operation.
HTTP 1.1 RFC location for POST
Difference between POST and PUT:
The RFC itself explains the core difference:
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request‑URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data‑accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request ‑‑ the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
Additionally, and a bit more concisely, RFC 7231 Section 4.3.4 PUT states (emphasis added),
4.3.4. PUT
The PUT method requests that the state of the target resource be
createdorreplacedwith the state defined by the representation enclosed in the request message payload.
Using the right method, unrelated aside:
One benefit of REST ROA vs SOAP is that when using HTTP REST ROA, it encourages the proper usage of the HTTP verbs/methods. So for example you would only use PUT when you want to create a resource at that exact location. And you would never use GET to create or modify a resource.
方法 2:
Only semantics.
An HTTP PUT is supposed to accept the body of the request, and then store that at the resource identified by the URI.
An HTTP POST is more general. It is supposed to initiate an action on the server. That action could be to store the request body at the resource identified by the URI, or it could be a different URI, or it could be a different action.
PUT is like a file upload. A put to a URI affects exactly that URI. A POST to a URI could have any effect at all.
方法 3:
To give examples of REST‑style resources:
POST /books with a bunch of book information might create a new book, and respond with the new URL identifying that book: /books/5.
PUT /books/5 would have to either create a new book with the ID of 5, or replace the existing book with ID 5.
In non‑resource style, POST can be used for just about anything that has a side effect. One other difference is that PUT should be idempotent: multiple PUTs of the same data to the same URL should be fine, whereas multiple POSTs might create multiple objects or whatever it is your POST action does.
方法 4:
- GET: Retrieves data from the server. Should have no other effect.
- PUT: Replaces target resource with the request payload. Can be used to update or create a new resource.
- PATCH: Similar to PUT, but used to update only certain fields within an existing resource.
- POST: Performs resource‑specific processing on the payload. Can be used for different actions including creating a new resource, uploading a file, or submitting a web form.
- DELETE: Removes data from the server.
- TRACE: Provides a way to test what the server receives. It simply returns what was sent.
- OPTIONS: Allows a client to get information about the request methods supported by a service. The relevant response header is Allow with supported methods. Also used in CORS as preflight request to inform the server about actual the request method and ask about custom headers.
- HEAD: Returns only the response headers.
- CONNECT: Used by the browser when it knows it talks to a proxy and the final URI begins with
https://. The intent of CONNECT is to allow end‑to‑end encrypted TLS sessions, so the data is unreadable to a proxy.
</ol>
方法 5:
PUT is meant as a a method for "uploading" stuff to a particular URI, or overwriting what is already in that URI.
POST, on the other hand, is a way of submitting data RELATED to a given URI.
Refer to the HTTP RFC
(by fuentesjr、Brian R. Bondy、Jonathan Arkell、bhollis、Jonatan Dragon、Daniel Bruce)