As far as I see, there's no RESTful way to apply a modification to a resource. In order to do it, you have to PUT the resource as a whole, overwriting the previous representation. I think this is source of problems, in particular when the resource has a large representation.
I believe this hints at the lack of a verb in HTTP1.1 : something like MODIFY, or PATCH. Not even WebDAV has this verb (it has PROPPATCH, whose concept is similar, but not for the resources).
Isn't the current HTTP 1.1 set of verbs too limited for real world RESTing ?
Edit: I found a proposal at IETF about the PATCH verb
https://datatracker.ietf.org/doc/html/draft-dusseault-http-patch-15
This specification defines the new
HTTP/1.1 [RFC2616] method PATCH
that is used to apply partial
modifications to a resource.
A new method is necessary to
improve interoperability and prevent
errors. The PUT method is already
defined to overwrite a resource
with a complete new body, and can not
be reused to do partial changes.
Otherwise, proxies and caches and even
clients and servers may get
confused as to the result of the
operation. PATCH was mentioned in
earlier HTTP specifications, but not
completely defined.
As far as I see, the only problem of such a verb is lack of idempotency.
Edit: As of March 2010, RFC 5789 exists (PATCH Method for HTTP).
You could partition the resource into individually updatable sub-resources.
E.g. you have a /user resource representing user account information you could create a /user/email sub-resource, then do a PUT on it to update just the email.
You can use POST for partial updates. It's not ideal, but it's fairly RESTful.
There is good reason there is no such verb to do this. It's almost impossible to manage. Think of 100's of clients modifying the same resource in this way, how do you know where your modification ends up? What if order matters, and your "patch" is actually added after another "patch" and now what you meant to add i actually not what was added. Using PUT with ETag headers is a much more sane approach to modifying a resource then trying to hobble together some new verb with unknown results. Having to actually GET the resource is a small price to pay for repeatable results.
I wish there were standardized and supported verbs like...
FIND, SEARCH, or QUERY - so its clear the request is not for a resource, but the locations of other resources. Maybe only limited usefulness.
MOVE, COPY, LINK - just damn handy, they'd act similar to the command line tools.
DISCOVER, MAP, INDEX, or SITEMAP - so you can get a layout of resources, similar in concept to a wsdl file, or xmlrpc's system.listMethods.
BEGIN, ACQUIRE, or LOCK, and COMMIT, END, DONE, or RELEASE - to make it clear when you're starting and ending transactions, or using intermediate resources.
MODIFY, UPDATE, PATCH - because we all want it
Related
Perhaps a partial duplicate of What is the correct http verb for a Download in a REST API? , though that is referring to a file download specifically.
In terms of CRUD operations, POST is the recommended HTTP verb for creating a resource. Does this still apply to creating resources, even if those resources are not persisted on the server? (i.e. stored in a database or similar) For example, generating some code based on code the client sent or converting a file and returning it to the client.
With such types of functionality, the server has indeed "created" something, though only in passing, returning or streaming it to the client, and not storing it in the traditional CRUD sense. I've always used POST for such functionality, but now I'm starting to double guess myself and think that those could have been GET endpoints the whole time.
Seems like a weird gray area in which neither HTTP verbs GET or POST completely match.
Is POST the correct HTTP verb for resources that are produced by but not stored by the server?
Yes - or alternatively, it's the least incorrect choice to use.
POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.” -- Fielding, 2009
In 2020, the HTTP-WG adopted a proposal to define a method token for "GET with a body", which would give as an alternative to POST when we want to indicate to general purpose components that the request has safe semantics, so there should eventually be some registered method that is a better fit.
There is no gray area here.
If the state of the server changes, use an unsafe method like POST. If it does not, you can use a safe methof like GET, as long as you stay within the documented limitations of GET (no request body).
If you're looking for a safe method that does take a request body, you may want to look at https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/.
From what I understand, PUT requests send the whole object while PATCH requests just send the diff, which is used to update the object in the database.
Why would you do a PUT over a PATCH? PATCH seems much lighter. I don't see any upsides to PUT (I'm sure they exist, I just don't know what they are).
A better way of looking at is that PUT replaces a resource, whilst PATCH is for providing an instruction to change a resource.
Replacing a resource is always a safe and idempotent operation as it has no dependency on the existing state of the resource. Meanwhile a request to change a resource may be dependent on the state of that resource and can therefore have other effects.
The HTTP PATCH verb is defined in RFC 5789, which states:
The difference between the PUT and PATCH requests is reflected in the
way the server processes the enclosed entity to modify the resource
identified by the Request-URI. In a PUT request, the enclosed entity
is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version
be replaced. With PATCH, however, the enclosed entity contains a set
of instructions describing how a resource currently residing on the
origin server should be modified to produce a new version. The PATCH
method affects the resource identified by the Request-URI, and it
also MAY have side effects on other resources; i.e., new resources
may be created, or existing ones modified, by the application of a
PATCH.
It goes on to say:
PATCH is neither safe nor idempotent
You might want to create the resource, or there might not be an applicable PATCH format available (think binary files).
with using POST as only option to create resources
only having JSON resources (RFC 7396)
making your PATCH endpoint implementation idempotent
Is there still a need to provide a PUT endpoint in an API?
Maybe I don't want to take the diff and deduce where I should save it so that everything makes sense. Maybe I just want to work with full resources instead of messing around with little parts of them. >> you can use PATCH for full update as well, no?
A considerable part of the HTTP standard is outdated, so it is not surprising that PATCH can completely replace PUT.
In RESTful API, people often mistakenly regard PUT as "update the entire resource", but in fact the semantics of PUT is "replace the resource". Unfortunately, there is a sad design in the HTTP: PUT is defined to create new resources when they don't exist, so PUT is sometimes used as an idempotent alternative to POST.
PATCH is an imitation of PUT to a certain extent, so it also incorporates part of the responsibilities of POST. However, if you only want to have an action of "modify the existing resource", you only need to use PATCH (PATCH is not idempotent, another sad design of HTTP).
Those who study REST and HTTP standard methods in depth will eventually find that a simple RPC interface can better implement all the actions you need.
I want to design a REST API to start a database. I can't find a suitable http method (aka verb).
I currently consider:
START /databases/mysampledatabase
I've browsed through a few RFCs, but then I thought someone here might point me to a de-facto standard verb.
Methods I've discarded (before I got tired of looking):
RFC 2616
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
RFC 2518
PROPFIND
PROPPATCH
MKCOL
COPY
MOVE
LOCK
UNLOCK
RFC 3253
REPORT
CHECKOUT
CHECKIN
UNCHECKOUT
MKWORKSPACE
UPDATE
LABEL
MERGE
BASELINE-CONTROL
MKACTIVITY
There's a bunch of thinking flaws here.. first off, the additional HTTP verbs (aside from the CRUD ones) should be considered not-restful.
So there's two ways I can interpret this question, and I have an answer for both:
1. What's the most appropriate HTTP method for starting a service
There's nothing quite like what you need, and I would advise simply using POST.
2. What's a good RESTful way to start a service
First, you should not see 'starting the service' as the action. It's easier to think of the 'status' (being started or stopped) as the resource you are changing, and PUT to update the resource.
So in this case, each service should have a unique uri. A GET on that uri could return something like :
{ "status" : "stopped" }
You just change 'stopped' to 'started', PUT the new resource.. and then the service could automatically begin running.
I wonder how useful this is though.. I'm not a REST zealot, and I think a simple POST is the best way to go.
edit I can't delete accepted answers, but since 2013 my thoughts on what is and isn't RESTful has nuanced quite a bit. I still think my example to represent the changable state of each service as a property still holds.
While reading some articles about writing web servers using Twisted, I came across this page that includes the following statement:
While it's convenient for this example, it's often not a good idea to
make a resource that POSTs to itself; this isn't about Twisted Web,
but the nature of HTTP in general; if you do this, make sure you
understand the possible negative consequences.
In the example discussed in the article, the resource is a web resource retrieved using a GET request.
My question is, what are the possible negative consequences that can arrive from having a resource POST to itself? I am only concerned about the aspects related to the HTTP protocol, so please ignore the fact that I mentioned about Twisted.
The POST verb is used for making a new resource in a collection.
This means that POSTing to a resource has no direct meaning (POST endpoints should always be collections, not resources).
If you want to update your resource, you should PUT to it.
Sometimes, you do not know if you want to update or create the resource (maybe you've created it locally and want to create-or-update it). I think that in that case, the PUT verb is more appropriate because POST really means "I want to create something new".
There's nothing inherently wrong about a page POSTing back to itself - in fact, many of the widely-used frameworks (ASP.NET, etc.) use that method to handle various events that happen on the client - some data is posted back to the same page where the server processes it and sends a new reponse.
I am learning about REST and PUT/DELETE, I have read that both of those (along with GET) is idempotent meaning that multiple requests put the server into the same state.
Does a duplicate PUT/DELETE request ever leave the web browser (when using XMLHttpRequest)? In other words, will the server be updating the same database record for each PUT request, or will duplicate requests be ignored automatically?
If yes, how is using PUT or DELETE different from just using POST?
I read an article which suggested that RESTful web services were the way forward. Is there any particular reason why HTML5 forms do not support PUT/DELETE methods?
REST is just a design structure for data access and manipulation. There's no set-in-stone rules for how a server must react to data requests.
That being said, typically a REST request of PUT or DELETE would be as follows:
DELETE /item/10293
or
PUT /item/23848
foo=bar
fizz=buzz
herp=derp
The requests given are associated with a specific ID. Because of this, telling the server to delete the same ID 15 times will end up with pretty much the same result as calling it once, unless there's some sort of re-numbering going on.
With the PUT request, telling the server to update a specific item to specific values will also lead to the same result.
A case where a command would be non-idempotent would typically involve some sort of relative value:
DELETE /item/last
Calling that 15 times would likely remove 15 items, rather than the same last item. An alternative using HTTP properly might look like:
POST /item/last?action=delete
Again, REST isn't an official spec, it's just a structure with some common qualities. There are many ways to implement a RESTful structure.
As for HTML5 forms supporting PUT & DELETE, it's really up to the browsers to start supporting different methods rather than the spec itself. If all the browsers started implementing different methods for form submission, I'm sure they'd be added to the spec.
With the web going the way it is, a good RESTful implementation is liable to also incorporate some form of AJAX anyway, so to me it seems largely unnecessary.
Does a duplicate PUT/DELETE request ever leave the web browser (when using XMLHttpRequest)?
Yeah, sure. Idempotence is only a convention and it's not enforced. If you make a request, duplicate or not, it will run through.
In other words, will the server be updating the same database record for each PUT request, or will duplicate requests be ignored automatically?
If it conforms to REST it should update the same database record twice, for example running UPDATE user SET name = 'John' twice. There is not guarantee what it will or will not do though, it depends on how it's implemented.
If yes, how is using PUT or DELETE different from just using POST?
It's just a convention. PUT and DELETE requests may or may not be handled differently from POST in the site's code.
I read an article which suggested that RESTful web services were the way forward. Is there any particular reason why HTML5 forms do not support PUT/DELETE methods?
I'm not really sure, to be honest. You can work around this by using a hidden <input> field called _method or similar and set it to DELETE or PUT, and then handle that server side.
PUT operation are idempotent but not safe operation. On success if PUT operation is repeated it will not insert duplicate records. Repeat PUT operation in case of NetworkFailure errors after verifying conditional headers like If-unmodified-since and/or if-match. Don't repeat in case of 4XX or 5XX error codes.
REST aims to establish a syntax convention regarding the HTTP method to use; each back end is free to implement anything they want, devs could break the convention but will cause unnecessary confusion if used by others not involved in the development.
For DELETE, if you delete some item with an ID, the server should responded it's deleted; if delete again, it's no more there so server responded "already removed", also good because your purpose is fulfilled. Same for PUT, because you provide the new status of your resource, the status yet-to-be; if it's already updated, mission complete and it's the same for the client.