Addressing Doubts about REST

Invariably, learning about REST means that you'll end up wondering just
how applicable the concept really is for your specific scenario. And
given that you're probably used to entirely different architectural
approaches, it's only natural that you start doubting whether REST, or
rather RESTful HTTP, really works in practice, or simply breaks down
once you go beyond introductory, 'Hello, World'-level stuff. In this
article, I will try to address ten of the most common doubts people have
about REST when they start exploring it, especially if they have a strong
background in the architectural approach behind SOAP/WSDL-based Web
services. (1) REST may be usable for CRUD, but not for 'real' business
logic. (2) There is no formal contract/no description language. (3) Who
would actually want to expose so much of their application's
implementation internals? (4) REST works with HTTP only, it's not
transport protocol independent. (5) There is no practical, clear and
consistent guidance on how to design RESTful applications. (6) REST does
not support transactions. (7) REST is unreliable. (8) No pub/sub support:
REST is fundamentally based on a client-server model, and HTTP always
refers to a client and a server as the endpoints of communication. A
client interacts with a server by sending requests and receiving
responses. In a pub/sub model, an interested party subscribes to a
particular category of information and gets notified each time something
new appears. How could pub/sub be supported in a RESTful HTTP
environment? We don't have to look far to see a perfect example of
this: it's called syndication, and RSS and Atom Syndication are examples
of it. A client queries for new information by issuing an HTTP against
a resource that represents the collection of changes, e.g. for a
particular category or time interval. This would be extremely inefficient,
but isn't, because GET is the most optimized operation on the Web. In
fact, you can easily imagine that a popular weblog server would have
scale up much more if it had to actively notify each subscribed client
individually about each change. Notification by polling scales extremely
well... (9) No asynchronous interactions. (10) Lack of tools: -- vendors
are coming up with more and more (supposedly) easier and better support
for RESTful HTTP development in their frameworks, e.g. Sun with JAX-RS
(JSR 311) or Microsoft with the REST support in .NET 3.5 or the ADO.NET
Data Services Framework... Is REST, and its most common implementation,
HTTP, perfect? Of course not. Nothing is perfect, definitely not for
every scenario, and most of the time not even for a single scenario.
I've completely ignored a number of very reasonable problem areas that
require more complicated answers, for example message-based security,
partial updates and batch processing, and I solemnly promise to address
these in a future installment.