Parse Releases Their REST API(parse.com) |
Parse Releases Their REST API(parse.com) |
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
Why is it that there's no examples of a truly restful web service in practice? The only one I can think of offhand is Sun Cloud's API, which is pretty dead. Its hard to espouse the virtues of a truly restful API when there aren't any examples to point at.
Edit: The downvotes would seem to just further my point...
I would like to learn how to do REST "right", and (for me) it's easier to learn by playing with a working example that deals with "real world" issues as opposed to abstract snippets that only show how APIs get used.
Any further insights/examples/pointers would be greatly appreciated.
He understands that most "RESTful" APIs out there leave HATEOS as an afterthought, but he doesn't believe there is such a thing as a 100% RESTful API - you match the architectural style to the context of the problem you are trying to solve.
So all apologies to Roy Fielding, but through success, he has lost control of his terminology. This is what people mean by REST today.
My point is, we should be careful before we corrupt a term. Doing so corrupts our perception of the concept itself. And if it turns out the corrupt concept is less help than the pure one, too late : it's already popular.
[1]: That assignment thing really sucks: http://www.loup-vaillant.fr/articles/assignment
It's weird how so many APIs don't feel like they were actually designed by programmers. This one, on the other hand, just looks right.
Edit: Spelling.
I would add that you must first have a deep understanding of the constraints and their associated benefits in order to make those types of informed decisions about your system's architecture. In my experience, the constraints are so orthogonal that a great number of the benefits of a system created using the REST architectural style only become evident in the overlap as the constraints empower each other.
Combining these constraints can elicit new benefits.
Be sure to read the first comment. I've sorta given up blogging about it, because I'm tired of fighting it. I am working on a side project, though, which exposes an actual Restful API, so maybe once I can use it as an example, I'll be able to blog more.
If I talk to someone who's not computer-savvy and they describe a workflow as "I put the USB in the CPU and then drag all my files onto my screen" (verbatim quote) I can figure out what they mean and work with them, but they clearly don't understand the concepts.
If someone wants to write a REST RFC, and people can talk about "RFC-6789 Compliant REST API" then correctness would reenter the picture.
I think you may have misunderstood your source. Subjective truth is only half of the equation. The other half is testing rational models against experience. If you understand the constraints of REST, you understand that it has implications not met by the API in question and thus claims to be something which it clearly is not.
Just because I tell you I'm a duck doesn't mean I'm a duck.
Much could be helped by 'the experts' just showing us rational laymen the cost-benefit analysis. Show me how things will fall apart over time, some data would be helpful. And let me see some case studies.
Currently, my non-REST "REST" interfaces seem to be working pretty well. And, when they don't work, I go and fix them. Seems easy enough, but obviously I'm naive.