Representational State Transfer in IoT

Rest stands for representational state transfer. It was introduced by Roy Fielding in 2000 in his famous monograph, at the University of California titled Architectural Styles and the Design of network-based software Architectures, It is an architectural style for distributed hypermedia systems to define the set of rules to be used for creating web services.

Web services that follow the REST architectural style are known as RESTful web services. Interaction is REST systems through Internet’s hypertext transfer protocol (HTTP) It permits requesting systems to access and manipulate web resources by using a uniform and predefined set of rules.

What is Representational State Transfer System

A restful system consists of –

A client who requests the resources.
The server has the resources.

Resource

The resource is the key component of information in REST. Any information can be a resource like a document or an image, a temporal service, a collection of other resources, etc. To determine the particular resource involved in the interaction between components, REST uses a resource identifier. At any particular timestamp, the state of the resource is known as resource representation.

A representation includes data, metadata, and hypermedia links which provide the clients with in transition to the next desired state. The data format of a representation is known as media Type. The media describes a specification and defines how a representation is to be processed. A truly Restful API looks like hypertext. Every addressable unit of information carries an address either explicitly or implicitly.

Resource Methods

Another important thing related to REST is resource methods. It is used to perform the desired transition. Resource methods are HTTP GET/PUT/POST/DELETE methods. It will decide HTTP post for updating a resource but if most people use HTTP PUT, the application interface will be Restful.

REST and the HTTP Methods

The default operation of HTTP is GET, which is predetermined to be used when getting data from the server. However, HTTP defines a number of other methods, including PUT, POST, and DELETE.

The REST philosophy provides to delete something on the server, which means simply using the URL for the resource and specifying the DELETE method of HTTP. For saving data to the server, a URL and the PUT method would be used. For operations that are more involved than simply saving, reading, or deleting information, the POST method of HTTP can be used.

Architectural Constraints of Restful API

There are 6 architectural constraints as follows:

Uniform Interface
Stateless
Cacheable
Client-Server
Layered System
Code on Demand

Uniform Interface

The main feature that differentiates the REST architectural style from other network styles is the uniform interface between components. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components or we can say that it determines that there should be a uniform way of interacting with a given server regardless of device or type of application (website, mobile app). Resources in REST-based systems should be uniquely identified, Through a single URL, and using network protocols such as DELETE, PUT, GET, and HTTP to manipulate a resource. For eg. a web page is a representation of the resource. REST is defined by 4 interface constraints.

Identification of Resources – Individual resources are identified in request eg- API/Users.

Manipulation of Resources through Representation – The client has a representation of the resource and it contains enough information to modify or delete the resource on a server provided it has permission to do so. For eg, when a user requests a list of users, the user gets a user id and then used that id to modify or delete that particular user.

Self Descriptive Messages – Each message contains sufficient information to explain how to process the message so that the server can easily analyze the request.

Hypermedia as the Engine of Application State (HATEOAS) – It includes links for each response so that clients can discover other resources easily.

Stateless

Stateless defines communication between the Server and Client must be stateless. That means the server does not need to know anything about what state the client is in and vice-versa. In this way, the client and server can understand any message received even without seeing the previous message. This constraint is executed through the resource rather than commands. Because REST systems interact through standard operation on resources, they do not rely on the implementation of resources.

In REST, the client must include all information to fulfill the request whether as a part of the header or URL, for the server. Statelessness facilitates greater availability since the server does not have to maintain, update or communicate that session state, these constraints provide RESTful applications that achieve reliability, and quick performance scalability, components can be managed, updated, and reused without affecting the whole system even throughout the operation of the system.

When the client needs to send more data to the server so it reduces the scope of network optimization and requires more bandwidth; this is the weakness of this constraint.

Cacheable

Cache constraints are added to the REST style to improve network efficiency, cache constraints require the data within a response to a request to be implicitly or explicitly named as cacheable or non-cacheable. If a response is cacheable, a client cache is given the right to reuse the response data for later, the same as the request. The advantage of this constraint is that client-server interaction partially or completely improves scalability, efficiency, availability, and performance. But sometimes there is a situation the user may receive stale data.

Client-Server

The principle behind this constraint is separation. In the REST style implementation of the client and server can be done independently without knowing each other. That means the code on the client side can be changed at any time without affecting the operation of the server and vice-versa. By separating the user interface from the data storage, we improve the portability of the user interface across multiple platforms and different improve scalability by simplifying the server components using the REST interface, different clients hit the same REST endpoints, perform the same action and receive the same response.

So we can say that the client and server expand independently. The server doesn’t need to know anything about frontend UI and same as the client doesn’t need to know anything about business logic.

Layered System

Layered system constraint is added to improve behavior for internet-scale requirements. A layered system allows an architecture to be composed of hierarchical layers with which components are interacting. Each lager does not know e anything about any layer other than that of the immediate lager. There can be a lot of intermediate servers between the client and the end server. The intermediary server can improve system availability to implement load – balancing and facilitate shared cache.

Code on Demand

This is an optional constraint. If a service violates any other constraint, it cannot be strictly referred to as RESTful. According to this, REST allows the server can also provide executable code to the client. for an eg. functionality may include the compiled components such as Java applets and client-side scripts such as JavaScript. This feature provides clients by reducing the number, of features required to be pre-implemented. This can also allow features to be downloaded after deployment improving system extensibility.

Creating a RESTful Service

Steps

Plan for things going wrong.
Create use cases to map events/usage.
Link data across resources (connectedness or hypermedia).
Define the representations to the client (XML, HTML, CSS, …).
Create URI to resource mapping.
Organize the data into groups.
Define the domain and data.

The given below image shows REST and Web Services.

REST and Web Services - rest — **REST and Web Services**

An application or architecture considered RESTful or REST-style is characterized by:

State and functionality are divided into distributed resources
Every resource is uniquely addressable using a uniform and minimal set of commands. (typically using HTTP commands of GET, POST, PUT, or DELETE over the Internet
The protocol is client/server, stateless, layered, and supports caching

This is essentially the architecture of the Internet and helps to explain the popularity and ease of use for REST.

Other IoT Tutorials