RESTful concept

Understand and evaluate the architecture design of network-based applications to obtain a powerful, high-performance, communication-friendly architecture. REST refers to a set of architectural constraints and principles. If an architecture conforms to REST constraints and principles, we call it a RESTful architecture.

REST itself does not create new technologies, components, or services, but the idea behind RESTful is to use the existing features and capabilities of the Web to better use some of the principles and constraints of existing Web standards. Although REST itself is heavily influenced by Web technologies, the REST architectural style is not theoretically tied to HTTP, but currently HTTP is the only instance of REST. So the REST we describe here is also REST implemented over HTTP.

RestfulAPI mapping

Understand the RESTful

To understand RESTful architecture, you need to understand what the phrase Representational State Transfer means and what each word means. We discuss about resources, listing some key concepts and explaining them from the perspectives of definition, acquisition, representation, association, and state change of resources.

  • Resources and URI
  • Unified Resource Interface
  • Representation of resources
  • Links to resources
  • Transition of state

Resources and URI

Uris represent resources, which typically correspond to entity classes in the server-side domain model

  • A URI is both an address and a resource
  • Uris contain version numbers and suffixes to distinguish statement formats
  • Necessary conventions
    • Use nouns, not verbs
    • The hierarchy is clear and is represented by /
    • To use? To filter resources

Unified Resource Interface

Standard HTTP methods include GET, POST, PUT, DELETE, and Patch, and their functions are listed below

The principle of the Get method execution process is as follows

The flowchart for executing the Put method is as follows

Security and idempotency

  • 1, security: does not change the state of the resource, can be understood as read-only;
  • 2. Idempotency: Execution once and execution N times have the same effect on resource state changes.
interface security idempotence
GET Square root Square root
POST x x
PUT x Square root
DELETE x Square root

Neither security nor idempotency guarantees that repeated requests will get the same response. Take DELETE as an example. If 200 is returned for the first DELETE, the deletion succeeds. If 404 is returned for the second DELETE, the resource does not exist, which is allowed.

Representation of resources

What is a resource? What is a statement?

In essence, anything important enough to be cited can be a resource. “If your users want to create hyperlinks pointing to it, point out or against assertions about it, or the cache it for expression, all or part of another statement refer to it, give it increase the annotation information, or to perform some operations on it”, (from the architecture of the world wide web), you should be defined it as a resource.

Every resource must have a URL. On the Web, we use urls to provide a globally unique address for each resource. Assign a URL to something and it becomes a resource.

Pomegranate can be a resource, but you can’t transfer it over the Internet, a record in a database can be a resource, and it can be transferred over the Internet.

When a client makes a Get request for a resource, the server responds with a document that collects the resource information in an efficient manner. This document of resource information is a representation, a machine-readable description of the current state of the resource

Resources have multiple representations

A resource can have multiple representations. For example, some resources can be expressed in an overall or exhaustive manner, or the same resource may be expressed in JSON format or XML format.

Connection of resources

We know that REST manipulates resources using standard HTTP methods, but it’s too easy to think of it as a Web database architecture with CURD.

This antipattern ignores a core concept: “Hypermedia as the engine of application state.” What is hypermedia?

When you browse the Web, jumping from link to page, and from link to page, exploits the concept of hypermedia: linking resources one by one.

To do this, include links in the presentation format to guide the client. In RESTful Web Services, the authors refer to this linked nature as connectivity. Let’s look at some specific examples.

Below is a github request for a list of projects under an organization. You can see that the Link header tells the client how to access the next and last pages in the response header. In the response body, the url is used to link the project owner and the project address.

The example above shows how hypermedia can be used to enhance the connectivity of resources. A lot of people spend a lot of time looking for nice URIs when designing RESTful architectures and ignore hypermedia. Instead of focusing on “resource CRUD,” spend more time providing links to resource representations.

Transition of state

Visiting a website represents an interactive process between the client and the server. In this process, data and state changes are inevitably involved;

Internet Communication protocol HTTP is a stateless protocol. This means that all state is kept on the server side. Therefore, if the client wants to operate the server, it must somehow make a State Transfer happen on the server side. This transformation is based on the presentation layer, so it is the “presentation layer state transformation”;

The client can only use HTTP. Specifically, there are four verbs in the HTTP protocol that denote operations: GET, POST, PUT, and DELETE. They correspond to four basic operations: GET to obtain resources, POST to create resources (and also to update resources), PUT to update resources, and DELETE to DELETE resources.

GitHub address of the blogger

github.com/yuyue5945