Menu
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.
972
Representational State Transfer (REST) is an architectural style that specifies constraints, such as the uniform interface, that if applied to a web service induce desirable properties, such as performance, scalability, and modifiability, that enable services to work best on the Web.
REST stands for representational state transfer. It is a set of constraints that set out how an API (application programming interface) should work. If an API is RESTful, that simply means that the API adheres to the REST architecture.
Some of the advantages of REST web services are: - Learning curve is easy since it works on HTTP protocol - Supports multiple technologies for data transfer such as text, xml, json, image etc. - No contract defined between server and client, so loosely coupled implementation.
SOAP is the most popular alternative to REST, and I found a few good links describing their differences and when to use which:
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.
20
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:
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!
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.
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.
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.
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.
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.
181
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
