“These new age sites don’t use pages I say. URLs don’t have a trailing dot extension any more. What sorcery is this?!” – burst one of my friends a couple of years ago. Developers off late have been going gung-ho about REST. But, why? “Why another layer? Why bring about another way to do something when we already have CORBA, WSDL, UDDI, IDL, XML, SOAP, and TOOTHPASTE.”
What you need to know about REST?
- It is not a standard.
- It’s not an architecture
- It’s not a technology
- It is not defined anywhere and does not have any validations for standards of compliance.
It’s simply an architectural style with constraints that set minimum requirements that qualify an application as RESTful. More accurately, it’s a state of the mind!
What you don’t need to know about REST?
- It stands for REpresentational State Transfer
- The WWW is the largest example of RESTful architecture
- In theory, REST is as old as the Internet
Once upon a time, Fielding and his buddies were poking around to develop the most efficient way to communicate between two machines. They realised that this was actually a very common real life situation.
Alice will ask Bob for a candy, and Bob will fetch and give it to Alice. But if Bob does not have any candy on himself, he will source it by asking others, namely Charlie, Dick, Eve… and then give it to Alice. A common language was needed, such that Bob could understand Alice is asking for. But as time went on, people invented new programming languages, databases and other tools, and machines started having a tough time talking to each other.
Essentially, Alice, Bob and Charlie are machines scattered all around the world asking each other for “things”, or resources. These resources are, by nature, nouns. Grammatically speaking, one can use a verb to express physical actions on a noun. But, you might say…
But some actions on resources are almost universal like GET, PUT, POST, DELETE. These resources could be pages, text, images, videos or blobs. Each of these systems would get information from each other using a simple HTTP GET. If one system needs to add something to another system, it would use an HTTP POST. If a system wants to update something in another system, it uses an HTTP PUT.
A basic problem we face on having resources on the web is while naming them. When we struggle to accurately name variables and methods in our own code…
That is when Fielding and Lee wrote a popular specification for identifying stuff on the Internet. They called their identifiers Uniform Resource Identifiers (URI), and in HTTP these URIs satisfy the REST constraint of Identifying Resources through one uniform resource identification scheme. Prime examples are the twitter profile URLs and Facebook account customised links.
Resources are polymorphic i.e may have more than one representation. When I type in a URL into a browser, the browser does a GET on all the required resources. Depending on how my browser makes a request, an understandable representation of the resource is received as response.
Example: When I request for a database, the database is returned in either JSON, XML or HTML depending on my request parameters. This represents the database records which can again be encoded in a requested format, like ASCII or UTF-8 and in my requested language like English or Hebrew.
Alternatively, if a human is asking for a resource, the RESTful URL can be a clean human readable address “http://www.site-name.com/user/records” which defaults to serve a response in HTML for the browser to render. And if the requester is a machine, the URL can be “http://www.site-name.com/user/records.xml” which is in XML and consumable by the machine directly.
This moves away from ugly URLs like : http://www.amazon.com/Fallen-Empires-Digital-Booklet/dp/B006MOPTPE/ref=amb_link_360086422_4?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=browse&pf_rd_r=1MAVSPWN5CBHYKJS02WR&pf_rd_t=101&pf_rd_p=1347080102&pf_rd_i=163856011
If you follow the RESTful architecture, you’ll build the web services required right into the fabric of your application. MVCs were introduced to move away from file-based delivery system to more of a Remote Procedure Call approach which is exactly what RESTful architecture brings to your application. The important thing here is that while building your application, you’re building a set of instructions for the web, which are a collection of consumable methods.
To implement the REST architectural style, one has to conform to a few constraints:
- Client–Server Model – A client makes a request to a server. Clients are not concerned with data storage, and servers are not concerned with user interface.
- Stateless – No client context should be stored on the server-side between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. Though, the server can be stateful on the condition that the server-side state be addressable by URL as a resource.
- Cacheable – Clients can cache responses and responses should implicitly or explicitly define themselves as cacheable or not to avoid clients from using stale/inappropriate data for future responses
- Layered system – A client need not know if it’s connected to the server directly or an intermediary system.
- Uniform Interface can be explained as follows:
- Each resource must be uniquely identified by a uniform resource identification scheme – URIs in the case of web-based REST systems. The resources are separate from the representations they have to offer.
- Manipulations of resources through these representations -Uniform representations like application/xml, application/json should have a uniform set of actions like GET, PUT, DELETE in HTTP to manipulate the respective resources.
- Self-descriptive messages – Messages provide uniform self descriptions about themselves, headers in HTTP, so that the receiver knows how to process them.
- Hypermedia as an Engine for Uniform State and State Transitions –
- Representations must capture the current state of an identified resource. That state is the current application state.
- Clients can make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g. by hyperlinks within hypertext)
REST vs The Rest
The battle with REST will go on. Ultimately, anything we use, we develop a taste for it solely based on interaction with the interface. Application users tend to flock towards uniformity and simplicity. They hate surprises. They hate rediscovering a similar page they visited a couple of days ago. UX experts preach that each node in the graph should have a set of uniform actions that one can perform on it. This was the one of the many arguments for the Facebook vs Myspace battle, and why Myspace lost out on it’s lead in the social web framework even though it has a huge lead over Facebook. There was no uniformity between user pages.
Uniformity might seem unimportant at the beginning when your data sets are small. But enter the world wide web, and users who use your app will promote it’s use by recommending it to others. Users generate large amounts of data. Large number of users and data generate desire in other users to use your app. Extra users create extra data and so on. This becomes a feed back loop where the input is amplified exponentially because, well, it is the world wide web. And there are no small data sets here. A simple and uniform interface is the key to manage both, more resources and more users.
Finally, the application you build using this architecture becomes completely transportable. Because your application takes an MVC approach, what you have created is not a site, but an application which consists of a series of pluggable units, which you can take apart or make it part of a bigger architecture. Time saved is definitely money saved.
Here’s hoping you’ll put this architecture to good productive use. I REST my case!
References: http://en.wikipedia.org/wiki/Representational_state_transfer http://tomayko.com/writings/rest-to-my-wife and https://blogs.oracle.com/allthingsrest/