REST Doubts
What are the most common criticisms/doubts people have about using RESTful HTTP?
Here is an initial list I’ve come up with (please note that I’m not conceding any of them are justified ;-) :
- REST may be usable for CRUD, but not for “real” business logic
- Who would actually want to expose so much of their application?
- Resources are too low-level, i.e. an implementation detail one should not expose
- There is no formal contract/no description language
- REST works with HTTP only, it’s not transport protocol independent (I shuddered when I wrote this)
- No transactions
- No reliability
- No (message-based) security
- No vendor/tool support
- No asynchronous interactions
- No pub/sub support
Did I miss any?
Maybe not specifically REST, but implied:
Thanks Gavin. I think these are much more uncommon and - coincidentally - much more justified :-)
Not object-oriented. [hysterical cackles]
Thanks Tim :-) I think it’s been a long time since someone actually advocated pure object-oriented concepts for remote-orientation … Michi Henning excepted, of course. OTOH, Mark Baker has been fond of arguing that he kept his “distobj” email address because HTTP has more OO heritage than Web services …
Thanks JJ. I wouldn’t exactly call these common — with the exception of the policy and event aspects, I consider them rather “JJ-specific”. Do you see a difference between the “events” and the “pub/sub” doubt?
REST’s biggest problem, BY FAR, is that there is no practical, clear & consistent guidance on how to design it.
Thanks! I couldn’t disagree more, but you are right that this comes up often.
I’ve got to agree with JJ on the versioning issue. Came up two times in a row, while I was giving talks on Service Design and RESTful Web Services.
I would also like to add “No Support for Concurreny” (he, he, one of my favorites!)
SOA is soooooooooo popular and I have never heard of REST.
[I actually hear this in my office :-( ]
You left off all the business level objections:
“I couldn’t disagree more”
Then can you point to any practical, clear & consistent design guidance?
Why does every supposedly RESTful API set vary so much, if there even is general agreement that they are RESTful in the first place?
I would argue that advice like this
http://www.xml.com/pub/a/2004/12/01/restful-web.html
is much more than you get anywhere in the WS world.
But I plan to write more about these doubts in an article — I’ll let all of you know once it’s online.
All verbs, no nouns! What is that resource then? (And don’t tell me that mime-types are enough).
Obviously you forgot #3 by a well-known authority in the field :-)
/blog/st/2007/06/11/ws_advantages.html
Thanks for the reminder :-) Let me take on those that I consider unfounded first. This is one of the few that I believe has merit.