Thursday, April 4, 2013

What is REST ?

Web services is a generic name for web-based RPC. This includes SOAP-based web services, which normally go by the proper name "Web Services"; but now, REST is also considered a web-service architecture.

REST is a non-XML-based, web-based RPC; but it is also a design philosophy and architecture.

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is a lightweight alternative to Web Services and RPC.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.)

REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture.

RPC is any mechanism that allows you to execute methods remotely (although some technologies adapted that as a proper name, it's a general name for many such technologies). This includes CORBA, Java RMI, SOAP-based Web Services, and REST. Some of these systems use binary data transfer (CORBA, Java RMI), and others are text-based; some of the text-based ones are actually XML-based.

XMLRPC is a general name for any XML-based RPC system, i.e., a system where the data that passes between client and server is XML data. There are generic XMLRPC systems (Java's JAX-RPC comes to mind) but when discussing XMLRPC, the key technology is SOAP-based Web Services.

SOAP is an XMLRPC web service, i.e., a web-based RPC that uses XML for data transfer, and more specifically, it uses the SOAP data format (an XML schema) for the queries and their replies.

 REST - Representational State Transfer, a new approach to systems architecture and a lightweight alternative to web services

Much like Web Services, a REST service is:
  • Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
  • Language-independent (C# can talk to Java, etc.),
  • Standards-based (runs on top of HTTP), and
  • Can easily be used in the presence of firewalls.

Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:
  • For security, username/password tokens are often used.
  • For encryption, REST can be used on top of HTTPS (secure sockets).
  • ... etc.

REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.

REST offers better performance than SOAP-based Web Services.

REST is every bit as secure as SOAP. In particular, REST can be carried over secure sockets (using the HTTPS protocol), and content can be encrypted using any mechanism you see fit. Without encryption, REST and SOAP are both insecure; with proper encryption in place, both are equally secure.


Using Web Services and SOAP, the request would look something like this:

For example of SOAP message (just for an example)

<?xml version="1.0"?>
 <soap:body pb="">

For example of REST message (just for an example)

Note that this isn't the request body -- it's just a URL. This URL is sent to the server using a simpler GET request, and the HTTP reply is the raw result data -- not embedded inside anything, just the data you need in a way you can directly use.
  • It's easy to see why Web Services are often used with libraries that create the SOAP/HTTP request and send it over, and then parse the SOAP response.
  • With REST, a simple network connection is all you need. You can even test the API directly, using your browser.
  • Still, REST libraries (for simplifying things) do exist, and we will discuss some of these later.

REST can easily handle more complex requests, including multiple parameters. In most cases, you'll just use HTTP GET parameters in the URL.

For example:

If you need to pass long parameters, or binary ones, you'd normally use HTTP POST requests, and include the parameters in the POST body.

Keyword : REST, stateless, protocol, CORBA, RPC, SOAP, CRUD, WSDL, RMI, Restful architecture, platform independent, HTTP request, 

Sources - wiki, stack, different websites and blogs