REST

Representational State Transfer

An image to create word manipulation

Today’s topic is Restful API, so get ready to learn a lot!

First, I want to touch an issue. Significantly large group of people, believe that REST is same as HTTP which is totally wrong.

REST stands as an acronym for REpresentational State Transfer. Briefly to say, it is an architectural style for distributed hypermedia systems. The term is brought to the market by Roy Fielding in his famous dissertation around the year of 2000.

It is said that if the topic is architectural style, then for sure there are some constraints hidden behind and that is totally true. REST also do own 6 guiding constraints. In another meaning without having them satisfied, the system cannot be called REST architectural.

Guiding Principles of REST

1. Client–server — By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
2. Stateless — Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
3. Cacheable — Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
4. Uniform interface — By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state
5. Layered system — The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.
6. Code on demand (optional) — REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented.

Resources

Since we talked about the rules, now the resource topic can be touched.

You may ask “why Resources?” , “what is special about it?” or “we all know about html, json, etc.” but this is actually why its is important to mention.

Resource in REST is a key abstraction of information.

Which indeed means that any information that can be named can be a resource, like a document or image, a temporal service, a collection of other resources, a non-virtual object (e.g. a person), and many more. As you understood, it is something more that you have thought of. Now I will try to mention some important phrases about the resources.

1. A resource identifier is used to identify the particular resource involved in an interaction between components.
2. A resource representation is known as the state of the resource at any particular timestamp. Moreover, A representation consists of data, metadata describing the data and hypermedia links which can help the clients in transition to the next desired state.
3. A media type is the data format of a representation. In more clear way, the media type identifies a specification that defines how a representation is to be processed.

It is said that, a truly RESTful API looks like hypertext which means every addressable unit of information carries an address, either explicitly(for example, link and id attributes) or implicitly(for example, derived from the media type definition and representation structure).

Resource Methods

Another important thing associated with REST is resource methods to be used to perform the wished transition. As I have mentioned above, a large number of people wrongly relate resource methods to HTTP GET/PUT/POST/DELETE methods.

To be honest, the original creator, Roy Fielding, has never declared any suggestion on what method to be used in what condition. The main notion he declares that the architecture should be uniform interface. For example, you can use HTTP POST to update resources rather than HTTP PUT and this is totally OK! The interface still will be RESTful!

REFERENCES

1. Untangled. (n.d.). Retrieved December 21, 2020, from http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
2. CHAPTER 5. (n.d.). Retrieved December 21, 2020, from http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm