Recently more and more Microsoft technologies are exposing REST API. WCF 3.5 added REST support, ADO.NET Data Services creates a REST interface over your Entity Framework / Database and many Azure Services are REST based.
So the question that naturally arise is: should I use REST or should I use SOAP?
Unfortunately is not so easy to answer because REST and SOAP are at the extreme opposites.
SOAP is now a quite complex, especially if you count all the WS-* stuff. It is probably even a bit over engendered protocol, creating a challenge to make it work across stack versions and platforms.
The big plus is that there is now a rich tooling available that makes life much easier at development time but also at runtime.
REST is not even a protocol but just a pattern on how to use HTTP for accessing, creating, updating and deleting resources. For a basic intro on REST you can look at this article in Wikipedia: http://en.wikipedia.org/wiki/Representational_State_Transfer
REST is extremely loose, basically you can do whatever you want in term of payload and is up to the consumer to figure out how the data is represented and even in which format like loose XML, AtomPub, JSON, etc…
View that there is no schema, the payload could even change at every request, making really hard to find out the payload structure. Without a good documentation it can become very hard to consume a service especially if you are not the one that has developed it.
REST is simple, efficient and most important super easy to interop with basically with no compatibility issue for accessing resources. With GET, PUT, POST and DELETE is a perfect fit for resource access. It really shines for accessing things like files in a Cloud FS like for Windows Azure Blob service , SQL Services data, documents in a CMS or whatever is a resource oriented. REST is simpler and more natural than FTP for example making it the right choice as Cloud Service API.
But REST It is not well suited, in my opinion, for “executing business actions” where there is a complex Business logic behind like a submit order, calculate price, login user.
Considering that you don’t have a schema, how do you figure out the format of the Order and how do figure out the service has changed? The only way is through a form of human written documentation that will be of course out of date and it will for sure not give you compilation errorsJ.
REST can be combined with JSON creating a very efficient transport system due to the very small payload. No SOAP envelope, no chatty XML format. This makes REST + JSON a perfect fit for applications that need to poll data very frequently and receive a small amount of data. Additionally it makes it super easy for platform like Phones, where soap toolkits are rare, to get access to this data. Stock ticker information is a good example where you will probably benefit from a REST+ JSON service.
Bottom-line in general REST is a thin “protocol” on top of a resource.
For example Microsoft ADO.NET Data Services enables you, with a couple of line of code, to create this thin layer on top of a Database (through Entity Framework) or IQuerable collections.
I find ADO.NET Data Services very good for public read only data like product catalogs where creating a SOAP/Schema based service will be too time consuming, tedious and costly.
ADO.NET Data Services is really cool when you want to expose a big data structure (in term of entities type and possible query variations) and you don’t need any big logic. Even better if the Data is mostly public and read only data. You can of course create validations, query inspectors, etc.. but is harder to close all the open gates than to open up one or two small ones..
Personally I don’t like it too much for CRUD operation because it tends to make you move some BL from the logic from service layer to the client and this is not always desirable.
I sometime wrongly refer it as ODBC over HTTPJ because with ADO.NET Data Services you can create queries on the client, something that is not always the best practice, making it harder to do access control and protecting the data.
To note that is not mandatory to create the query on the client and use it like a DB driver. But it is so easy and convenient to do it that most people will eventually do in this way.
It is definitively harder with ADO.NET Data Services to figure out all the possible calls that a client can/could make, making security harder to implement compared to the classical SOAP approach.
To conclude, REST is very easy and well suited when you need to access resources but in my opinion is not well suited when you want to expose services with strong Business Logic like submit order, calculate price, generate an offer, login a user, etc… where SOAP is a better approach.
Some MS technologies like SQL Data Services offers both a REST and SOAP interface allowing you to chose the one that fits you best.
WCF, from 3.5 on, let you easily create a REST interface. With the same technology you can now create both REST and SOAP interfaces.
We are only at the beginning of this debate and as more REST tools/technology will come to the market the more difficult will be to chose which one fits better.
Today It really depend on the scenario. One is not better than the other it is just fits better a particular needs.
Learn both and use them where it make sense. Easy to write, hard to do it.