What is Rest Full Service?
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..
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.
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.
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.
How Simple is REST?
querying a phonebook application for
the details of a given user. All we have is the user's ID.
Using Web Services and SOAP, the
request would look something like this:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:body
pb="http://www.acme.com/phonebook">
<pb:GetUserDetails>
<pb:UserID>12345</pb:UserID>
</pb:GetUserDetails>
</soap:Body>
</soap:Envelope>
And with REST? The query will probably
look like this:
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.
A nice analogy for REST vs. SOAP is
mailing a letter: with SOAP, you're using an envelope; with REST,
it's a postcard. Postcards are easier to handle (by the receiver),
waste less paper (i.e., consume less bandwidth), and have a short
content. (Of course, REST requests aren't really limited in length,
esp. if they use POST rather than GET.)
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:
As a rule, GET requests should be for
read-only queries; they should not change the state of the server and
its data. For creation, updating, and deleting data, use POST
requests. (POST can also be used for read-only queries, as noted
above, when complex parameters are required.)
In a way, this web page (like most
others) can be viewed as offering services via a REST API; you use a
GET request to read data, and a POST request to post a comment --
where more and longer parameters are required.
REST Server Responses
A server response
in REST is often an XML file; for example,
<parts-list>
<part
id="3322">
<name>ACME
Boomerang</name>
<desc>
Used by Coyote
in <i>Zoom at the Top</i>, 1962
</desc>
<price
currency="usd" quantity="1">17.32</price>
<uri>http://www.acme.com/parts/3322</uri>
</part>
<part
id="783">
<name>ACME
Dehydrated Boulders</name>
<desc>
Used by Coyote
in <i>Scrambled Aches</i>, 1957
</desc>
<price
currency="usd" quantity="pack">19.95</price>
<uri>http://www.acme.com/parts/783</uri>
</part>
</parts-list>
However, other
formats can also be used; unlike SOAP services, REST is not bound to
XML in any way. Possible formats include CSV (comma-separated values)
and JSON (JavaScript Object Notation).
SOME REAL REST EXAMPLES
The Google Glass
API, known as "Mirror API", is a pure REST API.
Twitter has a REST
API
Flickr,
Amazon.com offer
several REST services, e.g., for their S3 storage solution,
Atom is a RESTful
alternative to RSS,
Tesla Model S uses
an (undocumented) REST API between the car systems and its
Android/iOS apps.
Key components of a REST
architecture:
Resources,
which are identified by logical URLs. Both state and functionality
are represented using resources.
The logical URLs
imply that the resources are universally addressable by other
parts of the system.
Resources are
the key element of a true RESTful design, as opposed to "methods"
or "services" used in RPC and SOAP Web Services,
respectively. You do not issue a "getProductName" and
then a "getProductPrice" RPC calls in REST; rather, you
view the product data as a resource -- and this resource should
contain all the required information (or links to it).
A web of
resources, meaning that a single resource should not be
overwhelmingly large and contain too fine-grained details. Whenever
relevant, a resource should contain links to additional information
-- just as in web pages.
The system has a
client-server, but of course one component's server can be another
component's client.
There is no
connection state; interaction is stateless (although the servers and
resources can of course be stateful). Each new request should carry
all the information required to complete it, and must not rely on
previous interactions with the same client.
Resources should
be cachable whenever possible (with an expiration date/time). The
protocol must allow the server to explicitly specify which resources
may be cached, and for how long.
Since HTTP is
universally used as the REST protocol, the HTTP cache-control headers
are used for this purpose.
Clients must
respect the server's cache specification for each resource.
Proxy servers can
be used as part of the architecture, to improve performance and
scalability. Any standard HTTP proxy can be used.
