Introductory primer on REST
Representational state transfer (REST) refers to a way to architect application programming interfaces (APIs)—usually the most common way. Despite its popularity these days, when REST was first introduced by Roy Fielding almost 20 years ago, it gained hardly any attention. It was only popularized years after Fielding’s dissertation was published and is now one of the most common API architectures.
What are they?
To understand and put together a REST API, we need to understand what an API is in the first place. As stated before, it’s an application programming interface, but what does that mean?
I like to think of APIs as translators or interpreters for communicating with alien or robotic species. When someone needs to extract information about a product/website’s functions, they can extract all the data available, but it gets communicated in a long, garbled mess. An API is a conduit the information goes through to be translated into something more readable and specific. With an API, instead of gaining access to all the data at once, someone can give an explicit query and receive an equally precise answer.
For example, without an API, if someone were to ask, “what’s x plus y?” they would get the whole alphabet back and have to sift through it for their answer. With the use of an API, they’ll get the answer, “x plus y equals z.” Different types of APIs work with different things—a REST API works in many cases, making it a popular and effective architecture, but other types are sometimes needed instead.
The baseline to understanding a REST API is understanding its conceptual idea of a resource and its related terminology. A resource is simply any information that can be named, like a document or image. Resource identifiers are used by the API to recognize the resource when two components are interacting. Similarly, the resource representation is quite literally the depiction of the resource, encoded in a transferrable format.
6 Rules for REST APIs
RESTful APIs have their own rules and constraints, of course. The six main principles that define an API as being RESTful or not are a uniform interface, client-server, stateless, cacheable, layered system, and code on demand (optional).
1.Uniform interface:
The uniform interface is fairly self-explanatory. The API’s interface must be consistent, and all resource representations as well. The resources should be able to be accessed through a common command and consistently modified. The architecture needs to be simply designed in order to qualify as RESTful.
2.Client-server:
Client-server as a principle corrals any UI concerns away from data storage concerns, which improves scalability and portability of the API.
3.Stateless:
Stateless refers to each request from the client to the server. Each request needs to contain all the necessary information that is needed for the request to be carried out.
4.Cacheable:
Cacheable means that data is allowed to be used later for similar/the same requests. In layman’s terms, it’s given the ability to be remembered.
5.Layered system:
The layered system is a style in which the architecture of the API is ordered in a hierarchical way. This way, the components are unable to realize the existence of other layers beyond the one that’s currently relevant to them.
6.Code on demand
The code on demand (optional) improves functionality. Code is executed as applets or scripts, which decreases the need for pre-installed features.
A common misconception is that any old HTTP-based interface is also a REST API, but this is incorrect on multiple levels. REST APIs must follow the above six regulations and must be driven by hypertext. REST APIs can use HTTP to transport messages and data, but it’s not necessarily a cut-and-dry feature, and the two are definitely not synonymous.
Infolob’s experience
Infolob has worked with a variety of businesses to implement RESTful API solutions. For example, we recently helped Disney re-structure their website with REST APIs to improve the usability on the administrator’s end. REST APIs are making it easier and more convenient for Disney to manage ticket purchasing and as well as simplifying the process of website upkeep management.
Of course, REST APIs and APIs, in general, are much more complicated than this, but from the perspective of someone who has little experience with them, understanding these six key rules are an important starting point for those who are going to work with them.
This post was written by Infolob’s resident writer, Carson Collins, with assistance from Director of Architecture and Delivery Girish Mallampalli. They can be reached at carson.collins@infolob.com and girish.mallampalli@infolob.com.
