REST Services

What Are RESTful Web Services?

RESTful web services are loosely coupled, lightweight web services that are particularly well suited for creating APIs for clients spread out across the internet. REST stands for REpresentational State Transfer.

What is REST architecture?

REST is a web-based architecture that employs the HTTP protocol. Every component is a resource, and each resource is accessed using a common interface that uses HTTP standard methods.

In a REST architecture, a REST Server just gives access to resources, while a REST client uses the resources to access and modify them. URIs/global IDs are used to identify each resource. To represent a resource, REST employs multiple representations such as text, JSON, and XML. The most often used is JSON.

HTTP messages

HTTP Verbs

The following table shows how HTTP methods are intended to be used in HTTP APIs, including RESTful ones.

The six architectural constraints of REST APIs

REST defines 6 architectural constraints which make any web service — a truly RESTful API.

❄️Uniform interface

❄️ Stateless

❄️ Cacheable

❄️ Client-Server

❄️ Layered System

❄️ Code on Demand

Now let's discuss these six architectural constraints in detail,

1. Uniform interface

While the client and the server change in different ways, it’s important that the API can still facilitate communication. REST APIs do this by imposing a standardized interface that can simply accommodate any connected software.

The HTTP protocols are used to create that interface in the majority of situations. URIs refer to resources and HTTP verbs (GET, PUT, POST, DELETE) are actions performed on resources. To make it easier to navigate across resources, use hypermedia (HATEOAS — Hypermedia As The Engine Of Application State).

“Once a developer becomes familiar with one of your APIs, he should be able to follow a similar approach for other APIs.”

2. Stateless

It implies that the state required to handle the request is included inside the request itself, and the server does not keep any session data. In REST, the client must supply all information required by the server to perform the request, whether in query params, headers, or the URI. Because the server does not have to maintain, update, or communicate the session state, statelessness allows for higher availability.

“No client context shall be stored on the server between requests. The client is responsible for managing the state of the application.”

3. Cacheable

Get Sanduni Jayasinghe’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

REST services should be cashable. Each response should state whether it is cacheable or not, as well as how long replies may be stored on the client-side. For every future request, the client will return the data from its cache, eliminating the need to transmit the request to the server again.

“Well-managed caching partially or completely eliminates some client-server interactions, further improving scalability and performance.”

4. Client-Server

A client-server architecture should be used for REST applications. A client-server architecture should be used for REST applications. A client is someone who requests resources but is unconcerned with data storage, which is handled internally by each server, whereas a server is someone who manages resources but is unconcerned about the user interface or user state. They can evolve independently.

“Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.”

5. Layered System

Here client does not see the underlying layers or complexities of the service. The client only knows the URI. The server is decoupled enough to have multiple players and intermediate services sitting in between client and server. The Client only deals with the abstraction of resource URI and verbs.

6. Code on Demand

Code on Demand is an optional feature. Servers can also give executable code to clients, as per this. Compiled components, such as Java applets, and client-side scripts, such as JavaScript, are instances of code on demand.

“All the above constraints help you build a truly RESTful API, and you should follow them. Still, at times, you may find yourself violating one or two constraints. Do not worry; you are still making a RESTful API — but not “truly RESTful.”

Compliance with REST constraints

🌿Performance

🌿 Scalability

🌿 Simplicity — Uniform interface

🌿 Modifiability — Change components while running

🌿 Visibility — Communication between agents

🌿 Portability — Components, by moving program code with data

🌿 Reliability

HTTP codes

The Status-Code element in a server response is a three-digit integer, with the first digit defining the response class and the remaining two digits serving no classification function. The initial digit has five possible values:

🌵 Informational responses (100–199)

🌵Successful response (200–299)

🌵 Redirection messages (300–399)

🌵 Client error responses (400–499)

🌵 Server error response (500–599)

Closing Thoughts

So far we have discussed what is REST services, The six architectural constraints of REST APIs, Compliance with REST constraints, and HTTP codes.

Thank you for taking the time to read ; If you enjoyed this article, share it with your friends and colleagues!