This is a wrong question to start with. My request and recommendation to those designing RESTful applications is to never start with the question of whether any given design decision is RESTful or not. After all, REST is an architectural style. An architectural style, on its own, serves no end function.
A healthy discussion around (a) whether a particular aspect of a design is RESTful or not, and (b) the pros and cons of that part of the design not being RESTful is definitely useful. But it is productive to stay away from such discussions when they turn dogmatic.
I have been holding off this post for over a month. But having seen the latest post titled Your Web Service Might Not Be RESTful If… by Paul Sadauskas, I am motivated to publish this (not that his post is dogmatic – it is certainly not). Originally, I was tempted to write this after reading a section titled "Yeah, but is it RESTful?" in Alexandros Marino's paper on RETRO. In my opinion, there is no need for such rationalizations.
This question is common in a number of discussions and articles about REST. There are megabytes of discussions on the web about whether using server-side sessions is RESTful or not, or whether updating a resource via HTTP method POST is RESTful or not, or how to design a certain feature to be RESTful.
There are a few reasons why I think this this is the wrong question to ponder about. My primary reason is that, a question like this often leads to dogmatic interpretations of REST’s interface constraints, preferring form over function.
Secondly, there is no one-size fits all architecture that suits every problem. In cases where your particular use case is specialized and does not either fit REST’s view of client-server applications, or needs to, for business, technical, or even security reasons, implement web services that are contrary to REST’s architectural constraints, not being RESTful may be the right solution. I can give some very compelling examples, but let me leave that for some other time.
It is far more important to learn to know when to apply which aspects of REST, the consequences of violating any of REST's constraints, and the impact your software infrastructure (like caches) has on your application. Rather than pondering whether a given design is RESTful or not, it is better to focus on how to make judicious tradeoffs, and on getting things done.
{ 18 comments… read them below or add one }
Well said.
Nice post. +1 on the thought that its important to implement what makes sense rather necessarily dictated by the book.
I have at times sensed people attempting to coerce practices which didn’t smoothly fit the notion of ReSTfulness into being argued to be ReSTful. I generally prefer to simply document what is not ReSTful, explain the reasons for the choice and not attempt to force a set of architectural choices or interpretations of what ReSTfulness means in order to be 100% ReSTful
How about “Does this use HTTP properly?”?
Even for HTTP, there are cases where you may have to make tradeoffs.
You’re right, it can easily descend into dogma. On the other hand, it’s a great way for newbies to learn about REST. I think as long the answers to the question don’t suggest that !REST=bad, all is well.
Agree ++!
I recently had a chat in the Java Symposium about this, and one person in the audience asked me, more and less: “Can you tell me why is it important to tell if an API es RESTfull or not? If it works for the problem at hand, let it be!”
My answer was in the lines that I completely agree. My position is very open: REST has a set of constrains, and your solution may benefit from all but one. Missing that one constraint will make you architecture not a RESTfull one, but if it works great! Problem is when people try to make their solution to adhere to REST constrains just to have the REST name tag on it. Or adds the tag to a bunch of URLs driven RPCs. Both things are incorrect, and can cause problems for integration, standardization, and communication. Even structural problems.
So, instead of dealing with the nuts and bolts, I proposed to talk at architectural level, first by understanding why my architecture should follow REST, why not, and if a subset is desirable.
After all, REST is an architectural style. An architectural style, on its own, serves no end function.
I don’t agree with this (or don’t understand what you wanted to say). Are you claiming this only for architectural styles or for any kind of abstract concept/model (e.g. finite state machines). Abstract concepts (arch. styles included) may be researched and conclusions may be drawn by studying them on their own. Saying that an abstraction is useless until there is a practical use for it is nonsense since, for example, transfer of knowledge, critical thinking and ability for generalization are often based on abstractions, not on implementations of those abstractions.
IMO, this goes much beyond making tradeoffs against REST to get something done. Developers, open source projects, and vendors need to be given some leeway in using REST as a brand. We need to be able to use REST to identify aspects of our products so that users have an idea of what we’re trying to accomplish. Of course, because we will need to make tradeoffs to get something done, our designs will not be perfectly restful, but we still need REST the brand to articulate our project or product goals.
@Ivan: Concepts and styles are indeed essential to learn, measure, explain and debate. The “end function”, IMO, is the software artifacts you build, and not what concepts/styles it uses.
@Bill: But isn’t it silly to market and sell products based on the architecture style it follows and not on what it does and how it benefits its consumers? IMHO, it is a poor choice.
@Subbu:
Being forbidden from using REST to describe your projects is like forbidding Hannah Montana from calling herself a musician. Just calling Hannah Montana an “entertainer” is pretty ambiguous. Plus, I know my daughters would find fault with some elitist jerk’s definition of what a “true” musician is.
Just think how silly it would be if you couldn’t describe or name your project/product with “object”, “aspect”, “object-oriented”, “service-oriented” because you had to make some trade-offs in your design or implementation? Imagine if REST were trademarked or standardized? There’s a whole set of well-known vocabulary that you wouldn’t be able to use to describe anything you were doing and you’d end up having to reinvent the whole shabang with your own words. Pointless and a complete waste of time.
Beyond that, marketing and selling products based on a style is done effectively throughout all industries. It conveys a direction and vision for your project/product line. Branding a product line based on a style conveys to a potential user how they will consume the offering. A name is the most efficient way of articulating to a potential user what you are trying to do.
In the end, my users don’t care what some angry academic says about me or my company. I’m just sick of spending all these engineering resources on a SOAP stack and all the crap tools you need just to have an ounce of productivity. If I have to use REST as a brand to steer my company and users away from WS-*, then, IMO, the end justifies the means. Spending time justifying my existence is a complete waste of time and energy.
@Subbu, @Bill:
I think you can’t just take a name some else coined, change the meaning and sell it as the original thing, can you?
One thing is the REST architecture style and another is the thing vendors are selling. Look at the sales pitch, unless they mention the architecture style constrains and why those are there (benefits), I feel they are selling buzzword meal. And one thing is what sales people sale, and another one what developers got.
So, selling the architecture style is fine if sold to architects. But taking the style, deriving from there development tricks and selling them as a package to developers is not selling the style, is selling a particular interpretation/implementation of that style.
There is were not academics, but industry practitioners that know about it, can evaluate the tool and say you are selling cat meat and not crab meat. See?
For instance, I can tell you that wrapped document style is not document style, but RPC style. Because I’m an academic (angry or not) that also codes, and evaluates tools, and I know when a tool is not delivering. And I can tell you that RPC in the wrapped document styles does not deliver the same performance as the real document style due to a full set of flaws in the implementation, server and user side.
What vendors should do is go talk to the angry academia and ask why the implementation will not deliver what REST promises, if you feel you are implementing what REST style promotes. If what academia tells you is missing is not what you are selling, then fine. If what academia tells you improves your tool, great!
What is not correct is take your old technology, wrap it in the current buzzword because it behaves similar, and then sell it as the real thing using the name. You have for instance a URI template engine, and you see REST has something to do with URIs, and then you create a tool to easy the RPC using URI templates and sell that as REST. See what I mean?
Do you know some perfumes that sell “our version of…”. That is what I mean.
@William –
Well said. I now see that the title of this post did lead to competing opinions. Bastardizing the terminology either due to ignorance or marketing needs is always a bad thing. It leads to permanent confusion and lost productivity. On the other hand, developers employing HTTP must understand what RESTfulness means, and try their best to use the principles and make judicious tradeoffs when it does not fit their environment.
But, until a company actually ships a project or product that somebody can actually use, it is completely unprofessional to accuse them of changing the meaning of a buzzword to sell and repackage old technology. Even more unprofessional to call them “marketing morons”. This is especially true if the effort is open source where even the initial planning phases are done in the public before a single line of code is written.
@Bill:
Sorry Bill, if you understood I was saying your company did that. Not at all, and that was not my intention.
I did say that is not correct. And to accuse a company of doing that, I have first checked on the product that is selling. That is for sure.
Now, I don’t read the part of marketing morons anywhere. Just in case, since I have that part of academy too, business admin, I can tell you marketing doesn’t sell with commercials indicating the nuts and bolts of something. They sell with benefits, with buzzwords and brand names. That is because each word contains a meaning all people in the target market understands. That is perfectly correct. If developers say you will deliver X, sales will sale X (with some greatness, granted). If you end up delivering Y, it is you the one to blame. If you deliver Y because community said it was X, then it is the community to blame. In all cases, academy is not the one to blame (well, in these cases they are not).
@William: I wasn’t inferring that you were accusing my company of anything, but was instead referring to things I’ve experienced within the rest community. Here’s one high-profile example. There are others. This is pretty much why I’ve unplugged completely from the rest-discuss list and instead chosen to interact with my own communities and users as well as less religious REST experts and evangelists like Subbu, Stephan Tilkov, and Mike Amundsen to name a few.
BTW, getting sales, development, community, customers, and users all on the same page is a difficult task. Thats why its important to set down a vision and a direction first and why, IMO, something as trivial as a name helps to articulate this vision.
@Bill.
No worries. Actually, any effort of tools vendors that rely on community needs and not imposing technologies are very welcome! I would love to participate on drafts of tools checking what is delivered and what not, and explaining why it is not delivering what is expected in the case that happens.
I would suggest not to get away, but understand why the opinions are there and provide flexible ways to change in case that other voices prove correct.
Cheers
Hi Subbu,
I’ve been thinking about your point recently, and through re-reading your article, I think the point of my RETRO model has not been communicated well enough (to you or anyone else for that matter). The reason I designed RETRO was as a thought experiment to show that a pattern for atomic transactions can be instantiated without violating the constraints of REST. As you know there has been much debate around this point. RETRO was not meant to be sold as a product, but to advance the debate. In fact, it is not even implementable as a module at all as it needs to be tightly integrated with the underlying API to begin with. So in the context of the thought experiment I described, I think examining whether it succeeds or fails in its ambitions is entirely appropriate.
Regards,
Alexandros
{ 2 trackbacks }