My understanding of RESTful API Architecture

a few common misconceptions

Do not assume that the RESTful API is designed to be as easy as the pseudo-static SEO, such as an API URL similar to HTTP://XXX.COM/BLOG/1, we can access the URL through the browser to read the article, but this does not mean that it is a RESTful Pi.

Also do not think that there is queryString in the URL is not a RESTful Api, such as http://xxx.com/users/?page=10&page_size=30

Not to mention that HTTP + JSON is a RESTful ApI. REST and http/1.1

Roy Fielding (the core developer of Apache HTTP Server, the co-founder of the Apache Software Foundation, and the head of the http/1.1 agreement Expert Group) summed up a set of theoretical frameworks and then used the guiding principles in this theoretical framework to guide http/ 1.1 The design direction of the protocol. He later elaborated on this theoretical framework in a more systematic and rigorous manner in his doctoral dissertation architectural Styles and the Design of network-based software architectures. A new architectural style is deduced using this framework, and a relaxed and enjoyable name REST is given for this architectural style.

Surely through this you have understood the inseparable relationship between REST and http/1.1. Many of the features of http/1.1 are the features of REST, such as the stateless nature of connectivity. And the REST. The five features are inseparable from the http/1.1 protocol. A comparison of URL forms between RESTful APIs and SOAP Web APIs from the design of an API that removes comments

We can design this to resemble:

Http://mengkang.net/?method=comment.del&id=x①

Http://mengkang.net/comment/del/id/x②

or other forms of URLs.

And the RESTful Api is:

[DELETE] Http://mengkang.net/comments/1③

In contrast, we can find ① and ②url, all of which have Del's action instructions.

The SOAP Web API takes the RPC style and uses a feature-oriented architecture, so when we design the SOAP Web API, the Prime Minister considers what features (or operations) should be provided high.

The RESTful Api is a resource-oriented architecture. is query, add, modify, delete, all this resource independent.

So we don't see the DEL keyword in ③url, and the ② and ③ are the most obvious. Learn more about RESTful APIs

We know that URLs are all called "Uniform Resource Locators (Uniform Resource Locator)" and are used to describe where a Web resource resides. RESTful Api is based on the HTTP protocol, will be similar to ① and ② This function-oriented URL style discard, restore the nature of the URL, its purpose is that a URL should be a resource, can not contain any action.

[POST] Http://mengkang.net/users//New [GET] HTTP://MENGKANG.NET/USERS/1//query [PATCH] http://mengkang.net/u SERS/1//Update [PUT] HTTP://MENGKANG.NET/USERS/1//overwrite, update all [delete] Http://mengkang.net/users/1//delete

Both the put and patch functions can represent updates, but slightly different, put most of the time means to update all the information of the resource, while patch updates some of the information.

Put and post also overlap some functions, can be a new resource, post, the address of the new resource is returned to the client by the server. This means that the client will not be able to predict the address of the resource before sending the POST request resource, which is very common in our API development, creating a new post, a new comment, and so on.

The address of the resource is less than the client knows in advance. Someone who is designed to use a put, such as a project star for someone on GitHub, might be designed to: Http://github.com/xxx/zhoumengkang/projectname/star Here "has already liked this project. "As a resource, you can use put, because when you delete this resource, you still have access to the URL."

There may be some more standard specifications or protocols later on where these functions intersect.

Finally, the head and Options,head request is the metadata of the resource, such as a photo, the meta data may contain, photos of the device, location, time, etc. The server generally returns the metadata for the corresponding resource to the client in the header collection of the response, which generally does not have a body part. The options is to send a "probe" request to determine what kind of constraint the request must have for a target address (such as what HTTP method should be used and the custom request header), and then send a real request based on its constraints.

Query string, such as filter filtering, sorting and token, is supported and does not conflict with the concept of a unique resource. I understand the stateless and unique resource design guidelines for API URLs

To cite a practical example, the curd of the user blacklist. We're designed as

[GET]/blacklist [PUT]/blacklist/{id} #把 ID added to the blacklist of the currently authorized user [DELETE]/blacklist/{id}

As above in the API design, first as in the URL design above, the login user UID is obtained through the authorization code. Is stateful, and second, because all of the resources the user accesses are the same address, which is contrary to the concept of a unique resource. If it is stateless, it is consistent with the concept of a unique resource. (This is only recommended by the restful, and the actual need for full compliance is subject to availability)

[GET]/user/{uid}