What are the best uses of REST services?

Question

I know sites like Facebook are now using REST services, but I am wondering of other applications that use REST and if there are specific situations when the use of REST is more warranted than other methodologies.

Answer 1

There are LOTS of REST interfaces out there: flickr, and Google's data APIs come to mind as two big examples.

REST is great for simple data interaction and stateless connections (similar to HTTP itself). SOAP is a common alternative, and is often used for more complex connections. REST is very popular these days and is a good place to start if you're just learning why you'd want to have a data interface. Designing REST interfaces is easy to learn and has low barriers to entry.

Answer 2

SOAP is the most popular alternative to REST, and I found a few good links describing their differences and when to use which:

• REST vs SOAP Web Services
• When to use REST and when to use SOAP
• RESTful Web Services

The gist of it is that REST is much more simple than its alternatives (especially SOAP), and should be used when all you need is basic functionality (create/read/update/delete), and your service is stateless.

If you want an example application that uses REST, CouchDB does. (I can't think of any other ones off the top of my head.) On top of that, lots of websites use it, such as Flickr, del.icio.us, Bloglines, and Technorati.

Answer 3

REST is not about CRUD data services. Yes you can use REST to do a CRUD like services but that's like saying Regular Expressions are for parsing email addresses.

Here is the best presentation I have seen to-date on the REST versus SOAP/RPC debate.

REST is much more focused towards solving the distributed client/server interaction than it is about dealing with server to server interactions. REST is about getting content in front of the user so they can choose what to do with it. REST is not about creating an Http based data access layer to decouple your application logic from its data store.

Atom Pub is a good REST implementation. The Netflix API is one of the best commercial REST apis. The Twitter API fails most of the RESTful constraints.

If you want accurate information about REST go to these places:

• http://roy.gbiv.com/untangled/
• http://tech.groups.yahoo.com/group/rest-discuss/
• http://www.innoq.com/blog/st/
• http://www.infoq.com/

Don't listen to the big vendors on the subject they are more interested in making their existing products buzzword compliant.

---

Follow-up:

There are a few reasons that I believe REST interfaces are more suitable for client/server interactions than server to server interactions. This is just my opinion and I am not trying to claim that this perspective is held by anyone other than me!

Many to 1 ratio

The benefits of caching and a stateless server become far more apparent when you are supporting many clients accessing a single server. A server-server communication is often 1-1 and rarely has a large number of servers communicating with a single server.

Loose coupling

REST is all about loose coupling. The idea is that you can continue to evolve the server without having to update clients. If you are considering implementing a REST service on server A that will be called by server B that is in the same room then the benefits of the loose coupling are diminished. It is not going to kill you to update a piece of software on both machines.

Hypermedia

The hypermedia constraint is about giving users choices based on the current application state. REST interfaces support ad-hoc exploration of a hyperlinked system. Server-server communication tends to focus on achieving a specific task. e.g. Process this batch of data. Trigger these events based on a schedule. Inherently there is no user sitting there making decisions as to which path to follow. The path has been predetermined based on parameters and conditions.

Performance

In a server-server communication scenario it may be critical to achieve maximum throughput. A binary protocol may be more suitable than Http. Latency may be critical in a server to server type of communication. In a client-server environment where one end is driven by a human the performance requirements are quite different and I believe the REST constraints are more suited to that type of interaction.

Interoperability

REST recommends the use of standard media-types as HTTP payloads. This encourages serendipitous re-use of the services provided. I think there are many more opportunities to re-use services that are intended for use by client applications than those aimed at other servers.

When designing REST interfaces I like to think that the consumer of the service is a piece of software that is under the direct control of an end-user. It is no coincidence that a web browser is referred to as a User-Agent.

Answer 4

There are many examples out there. GData and the Atom Pub Protocol are probably the finest. Twitter seems to have a nice REST API also. Amazon's S3 service is also quite "RESTful". Unfortunately, many services that claim to be RESTful violate the very core priciples of REST as laid out by Roy Fielding in his dissertation that described the REST architectural style.

REST is an architectural style, not a set in defined standard or implementation. This makes it more difficult to say what is and isn't a REST service, that's why you'll often hear "RESTful".

REST can be a great (and simple) alternative to SOAP, XMLRPC, and in some cases things like DCOM and CORBA. It can be a very simple way to facilitate basic distributed computing and a simple way to expose an API... especially due to the face that it integrates so nicely into the ubiquitous HTTP.

Answer 5

REST is efficient when your ultimate goal of the data is the CRUD operations, usually within a web UI, usually with AJAX, Flash, Silverlight kind of experiences, when security, encryption, transactions are not the concern, however if your requirements includes any enterprise like features mentioned before (Transactions, Encryption, Interoperability ... etc) SOAP is the solution.

Answer 6

You should consider what your clients want! Building a big SOAP service that nobody wants to consume will be a waste of your time. Similarly, if your potential users are steeped in SOAP then maybe that's what you should give them.

If you don't know what your users want, consider the sentiment of the industry. Most companies that expose a public API these days expose a REST API. I really like how Foursquare has documented theirs: https://developer.foursquare.com/overview/