The architecture of RESTful has been around for a long time, but it seems like the word has been popping up a lot lately, and it’s not clear whether it’s because of the maternity effect of writing RESTful programs myself, or because of the popularity of single-page development.

In fact, I did not want to write this article at the beginning, because there are a lot of articles related to restful on the Internet, and all of them are well written and have relatively high reference value. However, when I looked through the articles I read, I found that people basically talked about the theoretical experience of restful, and there didn’t seem to be much mention of some experience summary of restful practical programming. And about this aspect of experience summary I have also tried to find for reference but failed to find, therefore, I write this article, I hope that some people can get some reference (because it is my personal practice, there may be some do not conform to the flow, please forgive or point out).

In addition, I will not talk about how to design some low-level restful support (how to design restful framework) in this article, it would be too long to say this, I will mainly talk about the application layer, that is, some specific business logic, of course, will do some basic extension.

resources

When it comes to restful, we have to say resources. Each interface of restful should correspond to a resource. So, in restful, the word “resource” should be an abstract concept, this “resource” contains more than the conventional sense of resources. I think it might be easier to call the resource objects instead.

Of course, first we should actually talk about what resources are. Resources contain many things, from images to audio, video and other data, as well as text are resources. That is, the data that exists on the server is a resource.

But it doesn’t make much sense to talk about resources alone, it makes sense to talk about how the resources are represented, or how the data are represented, which is important here, and this relates to the rest of what I’m talking about in restful design. Generally speaking, when we open a URL, we see a complete HTML interface. In fact, the HTML interface is the resource, and the images, audio, video and so on displayed by THE HTML are resources. At this point, some people may have misconceptions during development, thinking that the restful style of retrieving resources is json data returned by the server. Here are a few concepts we should be clear about:

  1. Data types: data types returned by the server, such as HTML, images, videos, Excel sheets, world documents, etc.
  2. Transmission mode: asynchronous and synchronous;
  3. Serial and parallel transmission: serial transmission waits for one data transfer to complete before transferring another data, while parallel transmission is performed simultaneously.

The three things I will not spread in detail, it is more complex, and I said look of serial and parallel with a general explanation of asynchronous and synchronous good, a lot of people think is asynchronous parallel execution, or asynchronous understanding into parallel execution, this is actually not necessarily, can only say that is executed asynchronously at the time of a process to perform other tasks can begin to perform, Reduce congestion.

Request way

The common request modes are GET, POST, PUT, DELETE, and OPTIONS.

GET: The interface literally understands that it is to obtain data. When we design, GET should contain two ways of obtaining data, one is to obtain the overall data list, and the other is to obtain data according to the specified ID.

POST: is used to add data, this request mode design interface is to add data;

PUT: is the data modification interface. If you want to make data modification to a resource, then the program should consider putting it in this interface.

DELETE: it is easy to understand that this request corresponds to the DELETE operation of the interface.

OPTIONS: This interface is designed to return information about the current interface, such as which fields are allowed and which fields are not allowed, etc.

The back-end business logic program should provide five basic interfaces, such as:

interface Api {
    public function index(a) {} // GET list interface/API
    public function view(a) {} // GET single data interface/API /:id
    public function create(a) {} // POST creates an interface/API
    public function update(a) {} // PUT Modifies interface/API /: ID
    public function delete(a) {} // DELETE Deletes the interface/API /: ID
}Copy the code

Direction of business logic design thinking

Well, having said all that, this point is probably the key thing.

Update: update: update: update: update: update: update: update: update: update: update From this point of view, it seems that modifications to resources are somewhat limited, as is deletion. And then, I think a lot of people are starting to wonder, “Oh my God, I’m going to do a batch fix. Isn’t that restful?” .

Yeah, that’s what I thought at first, and then WHEN I thought about it, I realized it wasn’t. As I mentioned earlier, any data on the server is a resource, and a resource should have an abstract meaning in restful terms. I can’t explain it above, but in fact, it’s a matter of programming.

First, let’s assume an example where we want to batch delete a bunch of commodity data. Traditionally, the user selects a batch of ids and passes them to the back end, which then deletes them based on the batch. I say this not to say that in restful thinking it doesn’t work, first of all it should be true, but what we need to do is to step outside of the thinking that was designed during this period. This is when we treat the item as a resource, and we should treat the “delete item” as a resource, not a commodity. That makes a lot of sense when we design interfaces. Treating “delete goods” as a resource, we’ll define this interface as /delete-goods for the moment. So, delete is the corresponding POST interface, that is, create “delete item”, so undo delete can be the corresponding delete interface, that is, delete “delete item”.

This may sound like a mouthful, but it’s really what it is. If we design this way, we follow restful standards, and the interaction flow is not much different from traditional, the only difference is the conversion of ideas. By analyzing the above, we should draw some conclusions:

  1. Do restful design, programming thinking should do a certain transformation, in different scenarios to think about what should be a resource, what should be regarded as a resource?

  2. Restful work should break down logic more cleanly, with each logical object doing five things: viewing list data, viewing individual data, adding data, modifying data, and deleting data.

Although I am talking about delete above, batch modification is also in line with this idea, including the question I answered earlier, that batch reading messages is also in line with this idea.

other

Restful interaction generally follows some data structure protocols or HTTP status values. For example, different operation results correspond to different HTTP status values, and specified error messages are returned to facilitate front-end prompt.

Of course, restful interfaces can also be designed to fully follow natural semantics by requesting lists of resources and using complex requests (singular and plural words in the language).

Regardless of the changes, I think the most basic thing is that different requests correspond to different operations, and all operations correspond to the same interface.

The above is my understanding and summary of some application scenarios, welcome to communicate with you.