What is REST?
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 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.
REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
One thing that is not part of a good REST design is cookies: The “ST” in “REST” stands for “State Transfer”, and indeed, in a good 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.
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.
A nice analogy for REST vs. SOAP is mailing a letter: with SOAP, you’re using an envelope; with REST, it’s a postcard.
One option is not acceptable as a REST response format, except in very specific cases: HTML, or any other format which is meant for human consumption and is not easily processed by clients. The specific exception is, of course, when the REST service is documented to return a human-readable document; and when viewing the entire WWW as a RESTful application, we find that HTML is in fact the most common REST response format
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).
Rather than letting clients construct URLs for additional actions, include the actual URLs with REST responses.
ROA (REST Oriented Architecture) is just a fancy name for a SOA (Service Based Architecture) using REST services.
With version 2.0, WSDL supports all HTTP verbs and it is now considered to be an acceptable method of documenting REST services. The second alternative is WADL, the Web Application Description Language
Read More: http://rest.elkstein.org/2008/02/for-more-about-rest.html
REST is neither a framework nor a technology. “REST is an Architectural Style built on certain principles using the current HTTP web fundamentals”.
A constraint is a rule that induces one or more software architecture properties. A group of constraints is called a style. The REST style is a group of six major constraints that induce the various properties needed for the Web. In order for architecture to be viewed as REST architecture, it must satisfy all of these constraints. They are:
- Stateless communication
- Uniform Interface
- Layered System
- Code On demand
Requests and responses are built around the transfer of representations of resources. A resource can essentially be any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.
The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition.
Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: presented with a network of Web pages (a virtual state-machine), the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.
REST was initially described in the context of HTTP, but it is not limited to that protocol.
SOAP vs REST
REST uses HTTP operations and other existing features of the HTTP protocol. For example, layered proxy and gateway components perform additional functions on the network, such as HTTP caching and security enforcement.
SOAP RPC over HTTP, on the other hand, encourages each application designer to define new, application-specific operations that supplant HTTP operations. An example could be: getUsers(), savePurchaseOrder(string CustomerID, string PurchaseOrderID)
This additive, “re-invention of the wheel” vocabulary — defined on the spot and subject to individual judgment or preference — disregards many of HTTP’s existing capabilities, such as authentication, caching, and content-type negotiation. The advantage of SOAP over REST comes from this same limitation: since it does not take advantage of HTTP conventions, SOAP works equally well over raw TCP, named pipes, message queues, etc.
An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI* in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information). For example, a resource that represents a circle (as a logical object) may accept and return a representation that specifies a center point and radius, formatted in SVG, but may also accept and return a representation that specifies any three distinct points along the curve (since this also uniquely identifies a circle) as a comma-separated list.
Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without “seeing past” its own request (referred to as “layering”, another constraint of REST and a common principle in many other parts of information and networking architecture). Thus, an application can interact with a resource by knowing two things: the identifier of the resource and the action required—it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML, XML, or JSON document of some kind, although it may be an image, plain text, or any other content.
* A URL is a URI that, in addition to identifying a web resource, specifies the means of acting upon or obtaining the representation: providing both the primary access mechanism, and the network “location”. For example, the URL http://example.org/wiki/Main_Page refers to a resource identified as /wiki/Main_Page whose representation, in the form of HTML and related code, is obtainable via HyperText Transfer Protocol (http://) from a network host whose domain name is example.org.
A URN is a URI that identifies a resource by name, in a particular namespace.
RESTful web APIs
A RESTful web API (also called a RESTful web service) is a web API implemented using HTTP and REST principles. It is a collection of resources, with four defined aspects:
- the base URI for the web API, such as http://example.com/resources/
- the Internet media type of the data supported by the web API. This is often JSON but can be any other valid Internet media type provided that it is a valid hypertext standard.
- the set of operations supported by the web API using HTTP methods (e.g., GET, PUT, POST, or DELETE).
- The API must be hypertext driven.
Hypermedia is used as a logical extension of the term hypertext in which graphics, audio, video, plain text and hyperlinks intertwine to create a generally non-linear medium of information. This contrasts with the broader term multimedia, which may be used to describe non-interactive linear presentations as well as hypermedia. It is also related to the field of electronic literature.
The World Wide Web is a classic example of hypermedia, whereas a non-interactive cinema presentation is an example of standard multimedia due to the absence of hyperlinks.
Multimedia development software such as Adobe Flash, Adobe Director, Macromedia Authorware, and MatchWare Mediator may be used to create stand-alone hypermedia applications, with emphasis on entertainment content.
A distributed hypermedia system provides a group of users logically transparent access to heterogeneous hypermedia information repositories that are distributed across local- and wide-area networks
REST Architectural Elements
Life is a distributed object system. However, communication among humans is a distributed hypermedia system, where the mind’s intellect, voice+gestures, eyes+ears, and imagination are all components.
The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system(eg. WWW).
REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application.
- 1. Connectors represent the activities involved in accessing resources and transferring representations
- 2. Components the various software that interacts with one another are called components
- Data Elements components communicate by transferring representations of the current or desired state of data elements. REST identifies six data elements: a resource, resource identifier, resource metadata, representation, representation metadata, and control data, shown in the table below:
Mashup services (ppt) can be built on top of RESTful APIs. Eg. Yahoo Pipes, Denodo, or JackBe/Presto.
REST principles such as simplicity, scalability, performance, reliability, visibility and evolvability will enable the framework interface to support human, mobile, mashup, and programmatic clients.
But REST has its issues: HTTP does not provide built-in quality of service (QoS) features such as reliability, security, transactional integrity, pub-sub, and event delivery.
We can have both method-oriented and resource-oriented interfaces by using a façade.
Security in RESTful Web services is limited. Encryption and digital signatures are handled by layering HTTP over TLS. Authentication is typically handled by supplying HTTP basic or digest credentials in the WWW-Authenticate header.
Implementing transport security using SSL impacts REST’s self-descriptiveness constraint. Public RESTful APIs such as Amazon and salesforce.com have invented their own solutions, usually incorporating access keys. Popular authentication solutions include self-provisioned developer keys, session-based authentication, WS- security, Open identity schemes like OpenID and OAuth or shared secrets used by AWS.
Check out Twillo, Twitter’s HTTP Push, and Granularity, Authentication and Exception handling. Explore Swagger, Mashape or Apiary.
Think this way about system design: Let go object orientation and RPC for resource orientation and hypermedia.
Intel’s Mashery [specially I/O docs], Apigee [used by MorningStar] make it easy to explore, test and debug APIs, 3scale with oAuth support or Layer7. Cloud API management services offer sophisticated caching mechanisms that improve application performance for dispersed users of Web, social and mobile applications.
Cloud Service Broker choices: Liaison, Appirio, Cloud Sherpas, StrikeIron, Kony.
Resource: The address (URI)
Representation of a resource : The data that the resource serves