REST

What is REST? REST Architecture and REST Constraints

What is REST?

This term “REST” was first defined by Roy Fielding in 2000. It stands for Representational State Transfer(REST). Actually, REST is an architectural model and design for server network applications. The most common application of REST is the World Wide Web itself, which used REST as a basis for HTTP 1.1 development.

What is the REST API?

A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. Representational state transfer (REST), which is used by browsers, can be thought of as the language of the Internet.

REST architectural Model

  • REST-REpresentational State Transfer
  • Resource-based
  • Representation
  • Six Constraints
    • Client-Server
    • Stateless
    • Cacheable
    • Uniform Interface
    • Layered System
    • Code-On-Demand

The REST architectural style describes six constraints. These constraints, applied to the architecture, were originally communicated by Roy Fielding in his doctoral dissertation and defines the basis of RESTful-style.

Resource-based

REST is resource based API because RESTful API is as below points

  • Things vs Actions
  • Nouns vs Verbs
  • Identified by URIs
  • Multiple URIs may refer to the same resource as like CRUD operation on student resource using HTTP verbs.
  • Separate from their representations-resource may represent as per as request content type either JSON or XML etc.

Representation

  • How resources get manipulated
  • Part of the resource state-transferred between client and server
  • Typically JSON or XML

For Example-

Resource– Author (Dinesh)
Service– Contact information about Dinesh (GET)
Representation-name,mobile, address as JSON or XML format

REST Constraints

REST architecture style describes six constraints for REST APIs.

1. Uniform Interface

The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently.

For us this means

  • HTTP Verbs (GET,POST,PUT,DELETE)
  • URIs (resource name)
  • HTTP response (status and body)

The four guiding principles of the uniform interface are:

1.1) Identifying the resource – Each resource must have a specific and cohesive URI to be made available, for example, to bring a particular user registered on the site:

HTTP/1.1 GET http://dineshonjava.com/user/dinesh

1.2) Resource representation – Is how the resource will return to the client. This representation can be in HTML, XML, JSON, TXT, and more. Example of how it would be a simple return of the above call:

{
"name": "Dinesh Rajput",
"job": "REST API Developer",
"hobbies": ["blogging", "coding", "music"]
}

1.3) Self-descriptive Messages – Each message includes enough information to describe how to process the message. Beyond what we have seen so far, the passage of meta information is needed (metadata) in the request and response. Some of this information are HTTP response code, Host, Content-Type etc. Taking as an example the same URI as we have just seen:

GET /#!/user/dinesh HTTP/1.1
User-Agent: Chrome/37.0.2062.94
Accept: application/json
Host: dineshonjava.com

1.4) Hypermedia as the Engine of Application State (HATEOAS)– Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver the state to clients via body content, response codes, and response headers. This part is often overlooked when talking about REST. It returns all the necessary information in response to the client knows how to navigate and have access to all application resources.

Just one example:

Request:
HTTP/1.1 POST http://dineshonjava.com/dinesh/posts
Response:

{
"post": {
"id": 42,
"title": "concepts REST",
"decription": "a little about the concept of architecture of REST",
"_links": [
{
"href": "/dinesh/post/42",
"method": "GET",
"rel": "self"
},
{
"href": "/dinesh/post/42",
"method": "DELETE",
"rel": "remove"
},
{
"href": "/dinesh/post/42/comments",
"method": "GET",
"rel": "comments"
},
{
"href": "/dinesh/posts/42/comments",
"method": "POST",
"rel": "new_comment"
},
{...}
]
},
"_links": {
"href": "/post",
"method": "GET",
"rel": "list"
}
}

2. Stateless

One client can send multiple requests to the server; however, each of them must be independent, that is, every request must contain all the necessary information so that the server can understand it and process it accordingly. In this case, the server must not hold any information about the client state. Any information status must stay on the client – such as sessions.

3. Cacheable

Because many clients access the same server, and often requesting the same resources, it is necessary that these responses might be cached, avoiding unnecessary processing and significantly increasing performance.

4. Client-Server

The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.

5. Layered System

A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.

6. Code-On-Demand (Optional)

This condition allows the customer to run some code on demand, that is, extend part of server logic to the client, either through an applet or scripts. Thus, different customers may behave in specific ways even using exactly the same services provided by the server. As this item is not part of the architecture itself, it is considered optional. It can be used when performing some of the client-side services which are more efficient or faster.

Summary

We have looked into REST Architecture design and its six constraints about REST API. Here we notice if the only optional constraint of REST architecture is code on demand. If a service violates any other constraint, it cannot strictly be referred to as RESTful.

Previous
Next
Dinesh Rajput

Dinesh Rajput is the chief editor of a website Dineshonjava, a technical blog dedicated to the Spring and Java technologies. It has a series of articles related to Java technologies. Dinesh has been a Spring enthusiast since 2008 and is a Pivotal Certified Spring Professional, an author of a book Spring 5 Design Pattern, and a blogger. He has more than 10 years of experience with different aspects of Spring and Java design and development. His core expertise lies in the latest version of Spring Framework, Spring Boot, Spring Security, creating REST APIs, Microservice Architecture, Reactive Pattern, Spring AOP, Design Patterns, Struts, Hibernate, Web Services, Spring Batch, Cassandra, MongoDB, and Web Application Design and Architecture. He is currently working as a technology manager at a leading product and web development company. He worked as a developer and tech lead at the Bennett, Coleman & Co. Ltd and was the first developer in his previous company, Paytm. Dinesh is passionate about the latest Java technologies and loves to write technical blogs related to it. He is a very active member of the Java and Spring community on different forums. When it comes to the Spring Framework and Java, Dinesh tops the list!

Share
Published by
Dinesh Rajput

Recent Posts

Strategy Design Patterns using Lambda

Strategy Design Patterns We can easily create a strategy design pattern using lambda. To implement…

2 years ago

Decorator Pattern using Lambda

Decorator Pattern A decorator pattern allows a user to add new functionality to an existing…

2 years ago

Delegating pattern using lambda

Delegating pattern In software engineering, the delegation pattern is an object-oriented design pattern that allows…

2 years ago

Spring Vs Django- Know The Difference Between The Two

Technology has emerged a lot in the last decade, and now we have artificial intelligence;…

2 years ago

TOP 20 MongoDB INTERVIEW QUESTIONS 2022

Managing a database is becoming increasingly complex now due to the vast amount of data…

2 years ago

Scheduler @Scheduled Annotation Spring Boot

Overview In this article, we will explore Spring Scheduler how we could use it by…

3 years ago