WebAPI prerequisites: HTTP, RestfulAPI, and webapirestfulapi

WebAPI prerequisites: HTTP, RestfulAPI, and webapirestfulapi

The basic understanding of the HTTP protocol is the basis for understanding and using RestFul APIs. After understanding these basics, you can use various RestFul development frameworks. When I first started using webapis, I had a lack of understanding of these knowledge and felt that they were not easy to use. I didn't feel comfortable using webapis until I became familiar with these HTTP knowledge, in my understanding, RestFul APIs provide excellent support for the HTTP protocol and implement the complete HTTP semantic style APIs.

Before introducing this knowledge, I need to emphasize a misunderstanding of many people: HTTP predicates and data transmission methods. The HTTP protocol that most people access and use is written on the website. In general WEB applications, we only use GET and POST predicates. Other predicates are not applicable, in this habit, many people have a few strange ideas: HTTP is only applicable to website development, and HTTP has only two predicates: GET/POST, HTTP calls data transmission only in the form of Form K-V; In this cognition, the RestApi developed with this style is often nondescribable, using ASP.. NET WebAPi will also look nondescribable, which makes it even more troublesome. First of all, we must realize that website data interaction is only a scenario in which HTTP can transmit various forms of data.

Starting from the first line of HTTP: the first line of HTTP contains three pieces of information: predicate, URL, and HTTP Protocol version. Separate the three data with spaces.

Predicates: for RestFul APIs, predicates are a very important element. WEB APIs use predicates as the default routing method. The most common predicates are POST, DELETE, PUT, and GET, these four predicates correspond to the four actions of "add, delete, modify, and query" (there is always a difference between POST and PUT statements about who adds and who changes different materials, i'm actually a little confused ...... PUT is a idempotent operation, but POST is not. PUT is more focused on modification, and POST is more focused on increment ). The most common predicates are the four, and other predicates have different semantics:

HEAD: returns only the corresponding header, excluding the Body.

TRACE: diagnose the data transmission process

OPTIONS: Requests the Web server to inform it of the various functions supported

There are other predicates that can be used to query relevant documents if needed, but are not commonly used.

The GET and DELETE operations do not contain the BODY, PUT, or POST operations. If a predicate contains operations other than semantics, such as GET with BODY, and POST is also allowed to delete resources, it is called a predicate overload, although HTTP supports predicate overloading, it is not recommended because it does not conform to standard semantics.

 

URL: a URL defines a resource. For example, www.example.com/person defines person as a resource. In combination with the predicates described above, we provide a group of operations for Person:

GET www. example/person/1: GET the information of the user whose ID is 1

POST www. example/person/(the BODY contains the description of Person) to create a Person Resource

PUT www. example/person/1 (the BODY contains the description of Person) update a Person Resource

DELETE www. example/person/1 DELETE the Person resource with ID 1

HTTP Version:

Currently, HTTP1.0 and HTTP1.1 are mainly used. HTTP2.0 is in the popularization stage and is not widely used. HTTP1.0 and HTTP1.1 are slightly different, but the difference is not very significant for RestFul. For specific differences, please refer to the relevant documentation.

The content of the first line of HTTP is this, followed by a \ r \ n for line feed, followed by the http head section, which describes the HTTP request and response. I think the HTTP HEAD is the most important part of the HTTP protocol. It contains encoding, BODY length, content negotiation, and other information. You can also include custom information. Next I will introduce several headers commonly used in RestFul APIs:

User-Agent: the User Agent, which client sends the request, such as IE, Chrome, and Fiddler.

HOST: domain name (HOST is generally used for server site binding. It is generally the same as the URL domain name, but in some custom DNS usage, the HOST and URL domain names may be inconsistent)

Authorization: authentication information. This field can contain some information for user verification. The representation method is schema authorinfo, which is separated by spaces. schema represents the verification method, authorinfo indicates the authentication information. A common schema such as Base: authorinfo uses the username + password and Base64 for encoding. Or use the Token, similar to the Session method.

Accept: Specifies the serialization method returned data. It is expressed by MIME. It is used to negotiate the content of the response data. It can contain multiple MIME types, which are sorted in priority, such as application/json, application/xml, text/html; the type of data that can be returned by the server depends on the server support. Some standard MIME types can be found; sometimes we also need some custom MIME, such as bson and protocolbuffer. We can customize MIME and develop our own implementations on the server side. These extensions are available in ASP.. NET WebApi has corresponding extensions.

Content-Type: uses a MIME to indicate the serialization method of the Body of the sent request. Common examples include application/json, in addition, the most commonly used application/x-www-form-urlencoded for WEB interaction represents the serialization method of your body part, which will appear in both requests and responses.

 

I think the HTTP HEAD part is the core part of the HTTP protocol. There are too many configuration and usage items, and there are too many details, the most common part of my work listed above is that all the information about the content is listed enough to complete a book. If you are interested, you can find relevant information. In the Rest API, content Negotiation often puzzles people who learn to use Rest at the beginning. Remember the roles and differences between Accept and Content-Type headers. Accept indicates what data they want to Accept, content-Type indicates the encoding method of the Body in the current request. In ASP. net webapi, if the request contains Content-Type without ACCEPT, the Content in Content-Type is used as the response Content negotiation by default.

The response part is also divided into the header and Body. The biggest difference between the response header and the request header is that there is an HTTP Code in the first line of the response. As an API call status, the HTTP Code is also very important, the most common status codes in REST APIs are 2XX, 4XX, and 5XX, while 1XX indicates that the work will continue, 3XX indicates redirection, and not many REST APIs are used. In the three most commonly used Status segments, 2XX indicates that the execution is successful, 4XX indicates that the client data error (for example, the parameter verification fails), and 5XX indicates that the server handles the error, for example, if an unhandled exception (such as a database connection error) exists, the status code can be used to preliminarily determine the execution status of the API call.

There is a blank line (\ r \ n) after the header, followed by Content. Here there are specific business data, which are represented by different serialization methods according to different Content-types, such as JSON, XML, or even HTML. When you learn HTTP APIs, you can think that web applications are also an application of HTTP, the interaction method is generally application/x-www-form-urlencoded as the request and text/html as the response. RestAPI can use many other encoding methods for interaction and supports a wider range. webpage applications only use HTTP transmission in application scenarios. RestAPI and webpage can be separated. I think Nancy is better than ASP. NET is doing better, Nancy does not split RestAPI and web pages, and ASP. NET uses MVC and WEBAPI to split the two. When requesting a data request, I can request that the Accept is application/json to return Json data, while the text/html to return a webpage. Of course, cutting or combining these two application methods have their own advantages and disadvantages.

I wrote too few or too few of these for the HTTP protocol. If you are interested, you can find relevant information on your own. I just wrote some of the commonly used WEB APIs, the following figure shows the knowledge: