Introduction to the

Microservices have been growing rapidly in recent years, and calls between microservices have gradually shifted from RPC calls to HTTP calls. It’s common to hear from colleagues that we provide microservices and expose RESTful interfaces to other systems, but what is a RESTful interface? How does it relate to REST? Don’t worry, this article will take you to find out.

REST

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.

REST is the full name of REpresentational State Transfer. Chinese may not be easy to translate, we temporarily define it as representative state escape. It is an architectural approach to distributed systems. It was first mentioned by Roy Fielding in his PhD thesis in 2000.

The REST architecture is very common in today’s Web applications. It does not involve specific coding. It is just a high-level guideline, and the implementation is up to you.

REST and RESTful API

We just covered REST, so what does REST have to do with RESTful apis?

As we know, API is the bridge of communication between services and between clients and servers. Through the invocation of APIS, we can get the required resource information from the server. RESTful apis are apis that conform to the REST architecture.

Not all HTTP apis are RESTful, but your system has a REST architecture.

Basic principles of REST architecture

So what kind of systems can be called REST architecture systems? According to Roy Fielding’s paper, a REST architecture system has six basic characteristics. We’ll show you.

Uniform Interface Uniform interface

In a REST architecture, the most central element is the resource. 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 unit that can be operated. These resources can be obtained and operated on in a common way. For example, the CURD of a resource can be represented by different HTTP methods (PUT, POST, GET, DELETE).

In addition, the resources must be named in a unified manner and the link format and data format must be defined in a unified manner.

Also, according to the HATEOAS protocol, a resource should contain urIs that point to the resource or related resources. Some of you may be a little confused about this right now, but that’s ok, we’ll talk about HATEOAS in more detail.

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

GET http://localhost:8080/greeting

The return of the request could look like this:

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

As you can see, it returns a link to the resource representing its URI.

Client-server The 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 API calls.

As long as the client can get the corresponding resource through the API, it doesn’t care how the server implements it.

As for the server side, it only needs to provide unchanged apis, and its own internal implementation is free to decide how the API is used by the client.

This rule is already used for many of today’s forward-end separated architectures.

Stateless Stateless

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

Therefore, the user status information is saved and maintained on the client. The client needs to carry a unique mark that identifies the user on each interface so that the client can authenticate and identify the user on the server to obtain the corresponding resources.

Cacheable Cacheable

Caching is a powerful tool to speed up the system. The same is true for REST resources, where cacheable resources need to be marked as cacheable.

The corresponding callers can then cache these resources to improve the efficiency of the system.

Layered System

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

Code on demand

In general, services in A REST architecture typically interact with each other through JSON or XML. But it’s not a hard and fast rule. Can return executable code to run directly.

RESTful API example

Let’s take a look at some examples of common RESTful apis to see the magic of this architecture:

Request an Entity:

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

Request an entity based on the ID:

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

Request an attribute of an entity:

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

Query using the filter:

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

Modify data:

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

Copy the code

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"
}
Copy the code

conclusion

This article has covered REST and RESTful concepts, so what are the most important resources? Stay tuned for further articles.

This article is available at www.flydean.com/01-rest-res…

The most popular interpretation, the most profound dry goods, the most concise tutorial, many you do not know the small skills waiting for you to find!