This seems to be a very powerful statement: why waste any time at all with REST?
With REST, all parties involved (providers and consumers) have to agree on most aspects of the design, as there are no standards beyond the actual (HTTP) GET, POST, PUT and DELETE.
What benefit could come out of REST?
Well, I think that to be able to offer a good operational answer to this question, we should picture a simple scenario.
Let’s suppose that you have an information system that maintains weather information for many locations, and you update that information into the system on a timely basis (like say, every 15 minutes).
As any system, it should support the usual CRUD functions: CREATE (INSERT), READ (SELECT), UPDATE (UPDATE), DELETE (DELETE).
You have many distributed weather data capture stations that send data to a centralized service following the aforementioned update period.
You need to offer a scalable and simple service façade to both the data providers (data capture stations) and the data consumers (other systems that query for weather info).
SOAP web services at first seem to be fine with this requirement (why shouldn’t they?).
But when you start thinking about quality attributes and architectural decisions that would better give support to those attributes, you start wondering…
One characteristic of the entire operation is a thorny issue: within each and every 15-minute period, data does not change!
So, all consumers of data for any given location (with the location ID being in itself a parameter of the query) would get always the same result within one given 15 minute period.
SOAP web services are great for highly transactional systems, that is, systems that are affected by high rates of data changes per unit of time.
For the kind of scenario that we are conceiving, SOAP web services are not necessarily that great, as we would benefit from a service that could make good use of web page caching mechanisms (that are very common on most web servers).
Well, the good thing about REST services is that, from the perspective of the web server where they are hosted, they appear and behave as simple web pages (to the server).
As that is the case, we can actually make good use of standard page caching mechanisms with REST services, in particular, with GET calls.
In WCF REST services, we can use standard Output Cache mechanisms (including cache profiles), starting with VaryByParam, VaryByParams and VaryByCustom.
So now, we have a better understanding of when and how to take advantage of REST services.