POST vs PUT
Let's get the facts on POST
and PUT
according to the Internet Engineering Task Force (IETF):
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.
Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that selects a proper URI on behalf of the client, after receiving a state-changing request, SHOULD be implemented using the POST method rather than PUT.
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4
Based on the above, POST
should be used to do MOST (if not all) of your CREATE or ALTER data routines on the server. Only POST is supported in HTML form field methods for this very reason, while PUT and DELETE are not supported in HTML forms (see below).
PUT
acts as a sub-type of the POST method as it can do only one narrow range of actions that POST does. Both POST and PUT can create and change data. The different is "intent". POST has no intention other than to work with the server's various ways of creating or altering the state of data. PUT has one intent...to REPLACE the state of ONE RESOURCE on the server with its own (which POST can also do, btw, and does often online).
Because of heavy use of JavaScript the past decade and XMLHttpRequest calls, this has opened the door up to websites using PUT and DELETE more often. WebAPI's are now configured to apply Http Method PUT and the rules to use it more consistently in 2023, than in the past. So the question has been raised, why use it, when we have been using POST to do the same thing successfully the past 20+ years?
I would ONLY use PUT in one case...where you are using JavaScript to create or alter the identity of a "resource" (state of an item), know the resource identity in your PUT (most often a URI/URL), and the WebAPI endpoint on the server strictly honors change the resource state with the one sent in the PUT. This must be total and complete, unlike with a post.
In the case of PUT, a good way to enforce this, rather than rely on sketchy JavaScript rules, is to rely on a UNIQUE IDENTIFIER in the URL on the server. This prevents PUT coming in without any rules or identifier. An example might be: https://example.com/123, with "123" being the ID of some resource or data point at the WebAPI endpoint.
The URI in a POST request does not need to identify the resource that will handle the enclosed entity or its state or what is changed. In contrast, the URI in a PUT request identifies the entity enclosed with the request and what will be replaced with the data or state in a PUT request.
BROWSERS DO NOT SUPPORT "PUT" or "DELETE"!
Did you know that HTML Form method
attributes in browsers the past 20+ years have only supported POST
and GET
, and do not support PUT
?
POST and GET work ok...
<form id="form1" name="form1" method="get" action="/form">...</form>
<form id="form2" name="form2" method="post" action="/form">...</form>
PUT NOT SUPPORTED!
<form id="form3" name="form3" method="put" action="/form">...</form>
DELETE NOT SUPPORTED!
<form id="form4" name="form4" method="delete" action="/form">...</form>
Crazy, huh?
When a browser user submits data to a server, nobody knows if they are creating, deleting, or modifying data. A POST can add or change an entity just like a PUT can, right? So, other than the identifying URL, the right action or HTTP Verb to use is most often POST. Therefore, PUT has always been optional in the traditional web world for decades.
When a form pushes data to the server, they are not honoring the HTTP VERBS as they were meant to be used. If you set up your server and HTML to follow conventions they would fail. AJAX or other JavaScript REST calls could override conventions and send a PUT meant for a POST for a given URL that is not an identifier type. But it would not matter today online.
To me, using PUT
comes down to JavaScript use and the URI or Unique Identifier; the structure of the URL "posted" to the browser. The server then must look at the Http VERY bit also the URL to decide what the method is honored, then route the POST or PUT or DELETE etc. to the right place or process the resource changes as required. Only this then honors the Post vs Put design.
It's the flawed nature of today's client-side model with its broken HTML5 design, plus the corrupting nature of today's thick-client JavaScript API calls and other circus-tricks, that have polluted what should have been a very simple HTTP Standard created long ago by very forward looking people. But adding PUT to today's mix, and honoring its narrow use with scripting and unique identifiers will help to clean up the messy web we have today.