No. The HTML 5 spec mentions:
The method and formmethod content attributes are enumerated attributes
with the following keywords and states:
The keyword get, mapping to the state GET, indicating the HTTP GET
method. The GET method should only request and retrieve data and
should have no other effect.
The keyword post, mapping to the state
POST, indicating the HTTP POST method. The POST method requests that
the server accept the submitted form's data to be processed, which may
result in an item being added to a database, the creation of a new web
page resource, the updating of the existing page, or all of the
mentioned outcomes.
The keyword dialog, mapping to the state dialog, indicating that
submitting the form is intended to close the dialog box in which the
form finds itself, if any, and otherwise not submit.
The invalid value default for these attributes is the GET state
I.e. HTML forms only support GET and POST as HTTP request methods. A workaround for this is to tunnel other methods through POST by using a hidden form field which is read by the server and the request dispatched accordingly.
However, GET, POST, PUT and DELETE are supported by the implementations of XMLHttpRequest (i.e. AJAX calls) in all the major web browsers (IE, Firefox, Safari, Chrome, Opera).
Overall:
Both PUT and POST can be used for creating.
You have to ask, "what are you performing the action upon?", to distinguish what you should be using. Let's assume you're designing an API for asking questions. If you want to use POST, then you would do that to a list of questions. If you want to use PUT, then you would do that to a particular question.
Great, both can be used, so which one should I use in my RESTful design:
You do not need to support both PUT and POST.
Which you use is up to you. But just remember to use the right one depending on what object you are referencing in the request.
Some considerations:
- Do you name the URL objects you create explicitly, or let the server decide? If you name them then use PUT. If you let the server decide then use POST.
- PUT is defined to assume idempotency, so if you PUT an object twice, it should have no additional effect. This is a nice property, so I would use PUT when possible. Just make sure that the PUT-idempotency actually is implemented correctly in the server.
- You can update or create a resource with PUT with the same object URL
- With POST you can have 2 requests coming in at the same time making modifications to a URL, and they may update different parts of the object.
An example:
I wrote the following as part of another answer on SO regarding this:
POST:
Used to modify and update a resource
POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/
Note that the following is an error:
POST /questions/<new_question> HTTP/1.1
Host: www.example.com/
If the URL is not yet created, you
should not be using POST to create it
while specifying the name. This should
result in a 'resource not found' error
because <new_question>
does not exist
yet. You should PUT the <new_question>
resource on the server first.
You could though do something like
this to create a resources using POST:
POST /questions HTTP/1.1
Host: www.example.com/
Note that in this case the resource
name is not specified, the new objects
URL path would be returned to you.
PUT:
Used to create a resource, or
overwrite it. While you specify the
resources new URL.
For a new resource:
PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/
To overwrite an existing resource:
PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/
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
created
or replaced
with the state defined by the representation
enclosed in the request message payload.
Best Answer
If your action is not idempotent, then you MUST use
POST
. If you don't, you're just asking for trouble down the line.GET
,PUT
andDELETE
methods are required to be idempotent. Imagine what would happen in your application if the client was pre-fetching every possibleGET
request for your service – if this would cause side effects visible to the client, then something's wrong.I agree that sending a
POST
with a query string but without a body seems odd, but I think it can be appropriate in some situations.Think of the query part of a URL as a command to the resource to limit the scope of the current request. Typically, query strings are used to sort or filter a
GET
request (like?page=1&sort=title
) but I suppose it makes sense on aPOST
to also limit the scope (perhaps like?action=delete&id=5
).