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.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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!
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.