Nevertheless, there are plenty of information systems that can be designed using the REST architectural style and gain the associated benefits. Managing cloud instances is certainly one of those applications for which REST is a good fit, as Stu Charlton has described several times. I am glad that Tim and others in the Kenai project are making the attempt, even if the first few iterations have some warts, and I approve of his stance that the design constraints of REST should be used when they are useful, not just because they are RESTful.

The Wikipedia article suffers from that and also because the folks writing it did not feel a need to constrain themselves to authoritative sources. There is not much I can do about the poor quality of the description aside from editing the article myself, which I’ve avoided doing because it would be too self-referential. Please feel free to fix it.

http://www.infoq.com/news/2009/04/post-state-appropriate#view_40928

My main concern is not actually the POST, but the way the REST is being forced into applications just by the sake of having it in its name!

Reading the HTTP spec, we can find what Post is supposed to do. And I think we can find a couple of ways for applying these semantics into the problem. But the issue is not the POST at the HTTP Spec, but the POST as REST is supposed to see it.

So, I feel we are trying to make the application fit into REST, instead of analyzing if REST is the suitable option for that application. Since REST is a style, and it is not the only one to work with web or networked applications, I guess the first question would be if my app solution requirements match those of REST and so it is good to follow that style, or we better go with any other that better matches my needs.

In Tim’s problem app, I can just guess that if he is struggling to map the elements and operations into resources and states, in a very artificial way (no natural to the app), we may be tweaking the app to fit the architecture. That is, wagging the dog.

What do you think?

William Martinez Pomares.

Of course the difference with the RESTful approach is that the URI and instructions for constructing the request body for the POST are represented in hypermedia and not baked into the client as with RPC. As you pointed out in your “REST APIs must by hypertext-driven” posting, most people don’t get this distinction (for reasons touched on in your follow up to that post). I’m not sure how this situation gets “fixed” but I don’t see it changing any time soon.

“Common REST” is all about using PUT and DELETE and organizing your data into CRUD-based interfaces. Hypermedia doesn’t really come into play beyond the recommendation to “put links to other resources in your representations”. This is of course lacking any sort of mechanism (e.g. a form) for constructing the request body of a POST. And so POST just isn’t used in any way other than asking a parent resource to create a child resource and assign a URI to it. e.g. it’s just a PUT where you are asking the server to assign a URI instead of supplying your own.

Common REST is winning mindshare over REST as you defined it. In an environment where the number of links defines authority that means Common REST IS REST.

Google “REST” and you will see that the wikipedia entry has the top position — that entry defines Common REST.

Andrew Wahbe

Thanks for the response – I’m still struggling to understand why ‘monitored’ state should be preferred as non-editable. Probably because I don’t see the power state as a monitored state, but simply as a state that is negotiated via the uniform interface (i.e. monitoring would be mapped to the GET method of the power resource).

Is a button a useful resource to identify? I’m not sure – In real world terms a button/switch seems more like a uniform interface than a resource in and of itself.

I don’t understand why a separate resource for monitoring is necessitated here – could this monitoring not be incorporated into the logic/state behind the power interface? Could that monitoring logic not ‘loop back’ on itself by addressing itself via its HTTP interface; thus keeping relevant intermediaries (and hence clients) ‘in the loop’, so to speak?

That’s probably enough points for now!

Thanks,
Mike

I agree that support for a PATCH method would be great (but first we’ve got to get people and browsers to even acknowledge that PUT and DELETE exist!). Until then, I think that giving POST this type of functionality makes things more complicated than need be.

POST’s function of treating request entities as “a new subordinate of the resource identified” has been most useful as a sort of factory for creating subordinate resources (e.g. POSTing to /article_id/comment to create a subordinate comment). If we also use POST for updates or a way of achieving partial updates, I think we loose the simplistic nature of our uniform operation set. There is now a bit of additional logic attached to the POST method – treat POST differently according to the context used.

I would agree with Stefan that PUT is still a better choice (in nearly all cases) by it’s definition and due to its idempotent nature.

If partial updates are desired, just provide URIs that have finer granularity (e.g. in our example, PUT /article_id/comment/123/name to edit just the writer’s name) and work with these as atomic units for PUTting. In many cases it can come pretty naturally and doesn’t require anything additional at the persistence layer.

I agree that there are REST zealots out there that get a bit carried away with dos and don’ts, especially since REST is a style and not a set in stone implementation, however, if you do choose HTTP as your uniform interface, I believe that until other methods become adopted, PUT is most appropriate for updates.

Thank you, I couldn’t agree more with you. I appreciate all your posts on the REST architectural style and feel exact the same way with regards to its relationship to the Web architecture. I mostly parrot what I believe is your sentiment in the following blog entry I wrote August 2008, in response to a few of your blog posts from the last half of 2008:

http://peskeflog.blogspot.com/2008/08/no-rest-for-wicked.html

Cheers,
Philip Eskelin

PATCH is another option that, once it is sufficiently deployed, might be preferred over POST for sub-resource updates. However, we make these choices for a principled reason, not just because it seems RESTful. Ultimately, the methods should be chosen by the origin server and communicated somehow to the client via the media type or relationship processing rules. If the choice of method doesn’t make any difference to the other components (i.e., neither client nor intermediaries gain any value by using PUT or PATCH over POST), then we should admit that it just doesn’t matter to the architectural style.