Architecture: REST and RESTful

Introduction

In recent years, microservices have been developing in full swing, and the calls between microservices have gradually shifted from RPC calls to HTTP calls. So I 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 through.

REST

REST is an architecture.

The first thing we have 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 not be easy to translate, we temporarily define it as a representative state escape. It is an architectural approach for distributed systems. It was first mentioned by Roy Fielding in his PhD 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 guide scheme. The specific implementation is still up to you.

REST and RESTful API

We just explained REST, so what is the relationship between REST and RESTful API?

We know that API is the communication bridge between service and service and between client and server. Through calls between APIs, we can obtain required resource information from the server. The RESTful API is an API that conforms to the REST architecture.

So not all HTTP protocol APIs are RESTful APIs. The premise is that your system is RESTful.

Basic principles of REST architecture

So what kind of system can be called a REST-based system? According to Roy Fielding's thesis description, the REST architecture system has 6 basic characteristics. Let us explain one by one.

Uniform interface

In the REST architecture, the most core element is the resource. We define resources as individual URIs. A resource is represented by an independent and unique URI.

A single resource cannot be too large or too small, it represents an independent unit that can be operated. These resources are acquired and operated through common acquisition methods. For example, the CURD of resources can be represented by different HTTP methods (PUT, POST, GET, DELETE).

At the same time, resources need to be named uniformly, and a uniform link format and data format should be defined.

Another point, according to the HATEOAS protocol, a resource should also contain a URI pointing to the resource or related resources. Maybe some students still have some doubts about this now, 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 like this:

{
  "content":"Hello, World!",
  "_links":{
    "self":{
      "href":"http://localhost:8080/greeting?name=World"
    }
  }
}

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

Client-server client and server are independent

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

For the client, as long as the corresponding resource can be obtained through the API, it does not care how the server implements it.

For the server side, you only need to provide APIs that remain unchanged. Your internal implementation can be freely determined, and you don't need to consider how the client uses these APIs.

This rule has already been used for many current architectures where the front and back ends are separated.

Stateless

Like the HTTP protocol, the API calls between various services in the REST architecture are also 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, every request is up-to-date.

Therefore, the user's status information is stored and maintained on the client, and the client needs to carry a unique mark that can identify the user on each interface, so as to perform authentication and identification on the server to obtain the corresponding resources.

Cacheable

Caching is a powerful tool to increase the speed of the system. The same is true for REST resources. In REST, cacheable resources need to be marked as being cacheable.

In this way, the corresponding caller can cache these resources, thereby improving the efficiency of the system.

Layered system

Modern systems are basically hierarchical. The same is true in the REST architecture. As long as the resource URIs provided to the outside are consistent, the architecture does not care how many layers of architecture you are using.

Code on demand

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

Examples of RESTful API

Let's give a few common RESTful API examples to see the magic of this architecture:

Request an entity:

GET https://services.odata.org/TripPinRESTierService/People

Request an entity based on ID:

GET https://services.odata.org/TripPinRESTierService/People('russellwhyte')

Request an attribute of an entity:

GET https://services.odata.org/TripPinRESTierService/Airports('KSFO')/Name

Use filter to query:

GET https://services.odata.org/TripPinRESTierService/People?$filter=FirstName eq 'Scott'

change the data:

POST https://services.odata.org/TripPinRESTierService/People
header:
{
    Content-Type: application/json
}
body:
{
    "UserName":"lewisblack",
    "FirstName":"Lewis",
    "LastName":"Black",
    "Emails":[
        "[e-mail]"
    ],
    "AddressInfo": [
    {
      "Address": "187 Suffolk Ln.",
      "City": {
        "Name": "Boise",
        "CountryRegion": "United States",
        "Region": "ID"
      }
    }
    ]
}

delete data:

DELETE https://services.odata.org/TripPinRESTierService/People('russellwhyte')

update data:

PATCH https://services.odata.org/TripPinRESTierService/People('russellwhyte')
header:
{
    Content-Type: application/json
}
body:
{
    "FirstName": "Mirs",
    "LastName": "King"
}

to sum up

This article explains the concepts related to REST and RESTful, so how to define the most important resources among them? Stay tuned for follow-up articles.

This article has been included in http://www.flydean.com/01-rest-restful/

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 discover!