Why REST?

Why REST?

 

Two reasons – One is soft and the other is hard( likely imposed).

 

1.    First, REST offers some significant features and benefits over RPC technologies in many cases.

2.    Second, Microsoft is moving many of its own implementations away from RPC technologies (such as SOAP) and goings toward REST. This means that even if you are not convinced or motivated to use REST to build your own systems, you'll need to know how to interact with other MS Frameworks & Technologies as they have already moved to REST,

 

Why Should You Care about REST?

 

For so long we have used either of the below two proprietary approaches.  These are the implementations of the client-server style we've had on the Microsoft platform.

·         RPC systems such as DCOM or .NET Remoting, or

·         Interoperable RPC technologies such as SOAP using ASMX(Web Service) or WCF,

 

So, apart from the two mentioned reasons, Why Learn Or Use Rest?

 

The following is a list of other advantages (but don't consider this list exhaustive):

Caching	When RESTful endpoints are asked for data using HTTP, the HTTP verb used is GET. Resources returned in response to a GET request can be Cached in many different ways.   Conditional GET, which is a way that a client can check with the service if his version of the data is still the current version, is an optional implementation detail a RESTful endpoint can implement that can further improve speed and scalability.
Scale-Out	REST encourages each resource to contain all of the states necessary to process a particular request. RESTful services are much easier to scale out when they fulfill this constraint and can be stateless.
Interoperability	Many people advertize SOAP as being the most interoperable way to implement client-server programs. But some languages and environments still don't have SOAP toolkits. And some that do have toolkits are based on older standards that can't always communicate with toolkits that implement newer standards.   REST only requires an HTTP library to be available for most operations, and it is Certainly More Interoperable Than Any RPC Technology (including SOAP).
Simplicity	Here, the simplicity of using REST relates to URIs representing resources and the Uniform Interface.   Using the uniform interface simplifies development by freeing me from having to build an interface, contract, or API for each service I need to build. The interface (how clients will interact with my service) is set by the constraints of the architecture.
Lightweight	REST is Lightweight than SOAP because it does not requires lot of xml markup like SOAP.

 

This is not an exhaustive list nor should you take it as conclusive evidence that REST is the one and only true technology to use always.

You should be aware of the advantages so you can leverage them when appropriate

 

REST Vs SOAP - Which is the best approach?

 

Software Architects have been involving a never-ending debate about whether SOAP-based or REST-style web services are the right approach.

Yahoo's web services are using REST and Google using SOAP for their web services. Some organizations have web services for both REST and SOAP.

 

REST is Lightweight than SOAP because it does not requires lot of xml markup like SOAP.

I believe that

 

·         SOAP will be the primary choice for Intranet & Enterprise Level Applications because SOAP and the WS-* specifications addresses many challenges of enterprise level applications such as Reliability, Distributed Transactions, and other WS-* services.

·         On the other hand, Internet applications will gear towards to REST because of REST’s explicitly Web-based approach and its simplicity.

 

Hope this helps.

 

Thanks & Regards,

Arun Manglick