What is the REST

REpresentational State Transfer (REST) specifies State Transfer. REST is a distributed hypermedia architectural style, derived from Roy Fielding’s paper. REST is a set of architectural principles, not protocols or standards, designed to help different software and programs communicate with each other across networks around the world.

REST6 big principle

1. Client-server

Improve portability and scalability of user interfaces across multiple platforms by separating user interface issues from data storage issues by simplifying server components. This C/S architecture makes the separation of concerns, and the server focuses on data storage, which improves simplicity; Front-end focus on page display, improve portability. Before there was no separation of the front and back ends, the back end not only needed data storage, but also needed to render the page through the template engine, which made the work of the back end complicated. A separate development model where the back end provides interfaces and the front end can use the interfaces on multiple platforms.

2. Stateless

Each request from the client to the server must contain all the information needed to understand the request, without taking advantage of any stored context on the server. Therefore, session state is completely retained on the client side. Consistent with the HTTP protocol, each request is a new one. Stateless ensures that the server does not need to save session information, improving simplicity, reliability, and visibility. Therefore, the server does not need to process user session information. Reliability refers to the stability of the software and the ability to recover when a fault occurs. If the server stores user session information, it is difficult to recover user information once the server fails and the user information is lost. Visibility refers to the transparency of the interface. Since the server does not store user information, each user request must contain all the information required for the request.

3. Cacheable

Cache constraints require that the data in the response to a request be marked either implicitly or explicitly as cacheable or not cacheable. If the response is cacheable, the client cache has the right to reuse the response data for future equivalent requests. For example, some static files (JS/CSS) need to be cached, so there is no need to re-request each time, which reduces the interaction between the front and back ends and improves the performance.

4. Unified interface

By applying general-purpose software engineering principles to component interfaces, the overall system architecture is simplified and interaction visibility is improved. The unification of interfaces improves simplicity. Once you are familiar with the style of one set of interfaces, you will understand the style of all interfaces, making development and communication easier. How to unify interfaces? To achieve a uniform interface, multiple architectural constraints are required to guide the behavior of components. REST is defined by four interface constraints: resource identification; Deal with resources through statements; Self-descriptive information; And hypermedia serves as the engine of application state.

5. Hierarchical systems

The layered system style allows an architecture to be composed of layers by constraining the behavior of components so that each component cannot ‘see’ beyond the immediate layer with which they interact. Example: middleware.

6. Code as needed

REST allows you to extend client functionality by downloading and executing code in the form of applets or scripts. This simplifies the client by reducing the amount of functionality required up front.

resources

A resource is anything that can be named. The key abstraction of information in REST is a resource, and REST uses resource identifiers to identify specific resources involved in interactions between components.

Unified Interface Restrictions

1. Resource identification

Each resource can be uniquely identified by a URI

    // Get the user
    https://api.github.com/users
    // Get a specific user
    https://api.github.com/users/:id
Copy the code

2. Manipulate resources by representation

Representation is representation, such as JSON, XML, etc. The client cannot operate server resources directly. It can only operate server resources through representation, such as JSON

    // Update user information
    octokit.request('PATCH /user', {
      name: 'name'
    })
Copy the code

3. Self-description information

Each message (request/response) must provide enough information for the recipient to understand, such as: media type (application/ JSON, application/ XML), HTTP method (GET, POST, PUT, DELETE), etc

$ curl -I https://api.github.com/users/octocat/orgs

>HTTP / 1.1 200 OK
> Server: nginx
> Date: Fri, 12 Oct 2012 23:33:14 GMT
> Content-Type: application/json; charset=utf-8
> Status: 200 OK
> ETag: "a00049ba79152d03380c34652f2cb612"
> X-GitHub-Media-Type: github.v3
> X-RateLimit-Limit: 5000
> X-RateLimit-Remaining: 4987
> X-RateLimit-Reset: 1350085394
> Content-Length: 5
> Cache-Control: max-age=0, private, must-revalidate
> X-Content-Type-Options: nosniff
Copy the code

4. Hypermedia as the engine of application state

Hypermedia: links with text, application state: web page, engine: drive, jump. Click the link to jump to another page

    // Get a specific user
    https://api.github.com/users/:id
    // Part returns information
    {
      followers_url: "https://api.github.com/users/kongjun0320/followers"
    }
Copy the code

RESTful API

1. Apis that conform to the REST architectural style

• The URI of the basic
• Standard HTTP methods
• Type of data media to be transferred

2. Resource naming conventions

• Use nouns to represent resources

• Use diagonal bars (/) to indicate hierarchy

• Use the hyphen (-) to improve the readability of urIs

• Use lowercase letters in urIs

• Do not use file extensions

• Don’t use underscores

• Filter the SET of URIs using the query component