Architecture: rest and restful


brief introduction

In recent years, microservices are developing in full swing, and the calls between microservices are gradually transferred from RPC calls to HTTP calls. Therefore, we often hear some colleagues say that we provide microservices and expose restful interfaces to other systems, but what is a restful interface? What does it have to do with rest?
Don’t worry, this article will take you to find out.


Rest is an architecture.

The first thing to remember is that rest is an architectural approach, not a protocol. It just tells us how to build a reliable system.

The full name of rest is representational state transfer. Chinese may be difficult to translate. We temporarily define it as a representative state escape. It is an architecture of distributed system. It was first mentioned by Roy fielding in his doctoral thesis in 2000.

Rest architecture is very common in today’s web applications. It does not involve specific coding. It is just a high-level guidance scheme. The specific implementation is up to you.

Rest and restful APIs

We just explained rest, so what is the relationship between rest and restful API?

We know that API is a bridge between services and between clients and servers. Through calls between APIs, we can get the required resource information from the server. The restful API is an API that conforms to the rest architecture.

Therefore, not all HTTP protocol APIs are restful APIs. Its premise is that your system is restful.

Basic principles of rest architecture

So what kind of system can be called a rest architecture system? According to Roy Fielding’s paper, the rest architecture system has six basic characteristics. Let’s explain.

Uniform interface

In the rest architecture, the core element is resources. We define resources as individual URIs. A resource is represented by a separate and unique URI.

A single resource cannot be too large or too small. It represents an independent operable unit. These resources are acquired and operated through common acquisition methods. For example, curd of resources can be represented by different HTTP methods (put, post, get, delete).

At the same time, it is necessary to name resources uniformly and define unified link format and data format.

Also, according to the HATEOAS protocol, a resource should also contain a URI pointing to the resource or related resources. Yes, some students still have some doubts about this, but it doesn’t matter. We will explain HATEOAS in detail later.

Spring also provides support for HATEOAS. Let’s look at a basic HATEOAS request:

GET http://localhost:8080/greeting

The return of the request can be as follows:

  "content":"Hello, World!",

You can see that a resource link representing your URI is returned above.

Client – server client and server are independent

Another rule is that the client and server are independent. The client and server do not affect each other. The only interaction between them is the call of API.

For the client, as long as the corresponding resources can be obtained through the API, it doesn’t care how the server is implemented.

For the server side, you only need to provide the same API. Your internal implementation can be decided freely, and you don’t need to consider how the client uses these APIs.

This rule has been used in many front-end and back-end separated architectures.

Stateless stateless

Like HTTP protocol, API calls between services in rest architecture are stateless. Stateless means that the server does not store the history of API calls, nor does it store any information about the client. For the server, each request is up to date.

Therefore, the user’s status information is saved and maintained at the client. The client needs to identify the user’s unique mark on each interface band, so as to authenticate and identify at the server, so as to obtain the corresponding resources.

Cacheable cacheable

Caching is a powerful tool to improve the system speed, and it is the same for rest resources. In rest, it is necessary to indicate that cacheable resources can be cached.

Thus, the corresponding caller can cache these resources, so as to improve the efficiency of the system.

Layered system

Modern systems are basically layered, and the same is true in rest architecture. As long as the resource URIs provided externally are consistent, the architecture doesn’t care how many layers you use.

Code on demand

Generally speaking, various services in rest architecture usually interact through JSON or XML. But this is not a hard and fast rule. You can return executable code to run directly.

Examples of restful APIs

Let’s take a few common examples of restful APIs to see the magic of this architecture:

Request an entity:


Request an entity based on ID:


Request an attribute of an entity:


Query with filter:

GET$filter=FirstName eq 'Scott'

Modify data:

    Content-Type: application/json
        "[email protected]"
    "AddressInfo": [
      "Address": "187 Suffolk Ln.",
      "City": {
        "Name": "Boise",
        "CountryRegion": "United States",
        "Region": "ID"

Delete data:


Update data:

    Content-Type: application/json
    "FirstName": "Mirs",
    "LastName": "King"


This article explains the concepts related to rest and restful, so how to define the most important resources? Please look forward to future articles.

This article has been included in

The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don’t know are waiting for you to find!