From Twitter to WordPress.com, many of the biggest and most popular web applications have developed RESTful application programming interfaces (APIs). While REST is enjoying a recent surge in popularity, it is not a new technology or approach. In fact, the term was originally coined in Roy Fielding’s 2000 dissertation. And though that is the first time REST was termed and defined, Fielding was merely codifying the underlying architecture of the world wide web.
What REST Is
REST is a style of architecture that is based off the interactions that happen all the time between a browser and a server when someone surfs the web. It’s important to realize that REST is more than simply a framework or product. It is a philosophy about how clients and servers should interact. REST stands for Representational State Transfer, and that will make sense by the end of this section. Let’s tackle this in parts.
Representational
The world of a RESTful API is made up of resources. For a blogging program like WordPress, resources would be things like posts, comments, pages. Resources can refer to static things like a particular page on a site or a particular part in an online catalog. They can also refer to concepts that are dynamic, like how a blog’s front page often shows its most recent posts or how Twitter has a URL to show the last several tweets from a user. While the resource can be either static or dynamic, the location (generally a URL) must be constant. To access the latest eight posts on this blog, you can always use this link.
Resources make up the nouns of the RESTful world. The verbs are taken care of by one of the oldest and most ubiquitous technologies on the Internet: HTTP. There are four HTTP verbs:
- GET – is used to request information from a resource. A GET request should never change the resource in anyway
- POST – is used to send information to a resource. For example, when you fill a comment form and press submit, it may send a POST request to /comments/new which is the location for every new comment.
- PUT – is used to modify a resource already on the application, like editing a post or changing the quantity of a part after a sale.
- DELETE – is used to delete a resource from the application.
The final key part of resources is that you never actually see them. When you access your timeline on Twitter on your smartphone, your phone sends a request to Twitter for the resource “latest tweets of people I follow.” Twitter then takes a snapshot of that resource of that time and sends your phone a representation. The resource can be an abstract, dynamic concept, but the representation is the physical data that is sent as a response. This provides flexibility for providing different representations for different clients, such as HTML for a browser and XML/JSON for a machine to machine call.
State Transfer
Imagine the number of people logged on to Twitter at any given minute either through their browser or on a mobile device. How much memory would it take to store the most recent tweet on every timeline? Luckily, since Twitter employs a RESTful API, they don’t have to worry about that. No information about the current state of the application is stored in the application. All the information necessary is included in the request or the response. Think of reading a long-form magazine article on their website. It’s likely split over several pages. The link to the next page in a non-RESTful API might be something like /article/0431/nextPage/. The server would know what page you are on and return the next page. A RESTful API needs all the information provided in the request, and so would have a URL like /article/0431/page4/.
While including all the information about the current state in the request can increase the request’s size, it ensures a one-to-one relationship between request and representation. This allows aggressive cacheing, which can greatly improve performance in large-scale applications.
Why REST?
REST has a very compelling, long-term use case: the Internet. While the scientists developing the very earliest world wide networks did not yet have the term REST, that is exactly what they are. REST is built on some of the oldest, most tested Internet technology out there, but is still incredibly flexible and robust. Furthermore, virtually every system that can connect to the Internet can handle HTTP requests, making it very interoperable and essentially platform independent.
More and more large scale web applications are moving from RPC/SOAP based solutions to REST. RESTful APIs are often almost self-documenting. If you peruse the Twitter or WordPress.com APIs I linked at the top of this article, you can see that the URLs themselves almost act as the documentation. In an era where mash-ups, mobile apps and interoperability are key to a web application’s long-term success, making your API available and technically accesible to the broadest range of developers is a killer feature. Taking Twitter for an example, hash-tags, search and @replies all sprung from developers incorporating them into apps before they were part of the Twitter platform.
How to Leverage REST for Your Enterprise
IBM Business Process Manager 7.5 is a BPM platform that is able to provide visibility and control over an enterprise’s business processes from an initial pilot project to an entire enterprise. BPM 7.5 provides a RESTful API that allows interaction, data retrieval, record modification, etc., via HTTP requests. This allows custom-built portal solutions to add further visibility and interaction with the business processes that make up the very core of any enterprise IT project.
IBM also offers SmartCloud Enterprise, an IaaS (infrastructure as a service). By leveraging SmartCloud, an enterprise can remain agile and adapt quickly to changes in demand and requirements. SmartCloud provides an API that can return either XML or JSON to requests from all four HTTP verbs. Leveraging this, an enterprise can make their resources available through remote HTTP calls, opening up collaboration with trading partners or other developers.
In future posts, I’ll explore using Datapower to secure RESTful applications.
Further Reading
- Elkstein, M. Learn REST: A tutorial
- Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.
- Tomayko, Ryan. How I Explained REST To My Wife.
