ASP.NET WebAPI pre-knowledge: HTTP and RestfulAPI

         A basic understanding of the HTTP protocol is the basis for understanding and using the RestFul style API. After understanding these basics, use various RestFul development frameworks can be handy. When I first started using WebApi, I felt that it was not comfortable to use because of my lack of understanding of this knowledge. It was not until I became familiar with these HTTP knowledge that I felt comfortable using WebApi to develop. In my understanding, RestFul style API is It is an API that has good support for the HTTP protocol and implements the complete semantic style of HTTP.

Before introducing this knowledge, I need to emphasize a misunderstanding that many people have: HTTP predicates and data transmission methods. The HTTP protocol that most people come into contact with and use is in the process of writing websites. In general WEB applications, we only use the two predicates GET and POST, and other predicates are not applicable. Under this habit, many people have Several strange cognitions: HTTP protocol is only suitable for website development. HTTP has only two predicates: GET/POST. HTTP call data transfer is only performed in the form of K-V. Under this cognition, develop in this style. RestApi is often nondescript, and using ASP.NET WebAPi will also appear nondescript, causing trouble. We must first realize that data interaction on the website is just one scenario of HTTP usage, and HTTP can transfer various forms of data.

We start with the first line of HTTP: The first line of HTTP contains three pieces of information: predicate, URL, and HTTP protocol version. The three data are separated by spaces.

Predicate: Predicate is a very important element for RestFul API. WEB API uses predicates as the default routing method. The most commonly used predicates are: POST\DELETE \PUT\GET, these four predicates correspond to the four actions of "add, delete, modify, and search" (POST and PUT are used to add and to modify different data. There are always different opinions. I am actually a little confused. La... There is a definition that PUT is an idempotent operation, but POST is not, then PUT is more focused on changes and POST is more focused on increases). The four most commonly used predicates are these four, and there are other predicates with different semantics:

HEAD: Only the corresponding header is returned, excluding the Body

TRACE: Yes Diagnose the data transmission process

OPTIONS: Request the Web server to inform the various functions it supports

There are other predicates. If necessary, you canqueryrelated documents, but not Commonly used.

Among them, GET and DELETE do not contain BODY, while PUT and POST can contain BODY. And if a predicate contains operations outside of semantics, such as GET with BODY, POST is used to delete resources. This operation is also allowed, and is called overloading of the predicate. , although HTTP can support predicate overloading, its use is not recommended because it does not comply with standard semantics.

URL: URL defines a resource. For example, www.example.com/person defines person as a resource. Combined with the predicates introduced above, we provide Person's group operation:

# Get www.example/Person/1 to get the user information of the user with id

## Post

www.example/person/ (in body Contains the description of Person) Create a Person resource

PUT

www.example/person/1 (The BODY contains the description of Person) UpdateA Person resource

                                                                                                                                                                                                                                   Deletes the Person resource with ID 1

1 protocol, the HTTP2.0 protocol is in the popularization stage and is not used much yet. The difference between HTTP1.0 and HTTP1.1 is very small, and the difference does not have a great impact on RestFul. For specific differences, you can check the relevant documents.

      

The first line of HTTP is these, followed by a \r\n for line break, and then the HTTP HEAD part. HTTP HEAD describes the HTTP request and response. I think HTTP HEAD is the most important part of the HTTP protocol. It contains information such as encoding, BODY length, content negotiation, etc. You can also include some custom information. Let me introduce to you some HEAD commonly used in RestFul API:

User-Agent: User agent, what client makes the request, such as IE, Chrome, Fid dler, etc.

HOST: Domain name (HOST is generally used for site binding of the server. It is generally the same as the domain name of the URL. However, in some customized DNS usage methods, it may appear The domain names in HOST and URL are inconsistent)       

     Authorization: Verification information, this field can contain some information for user verification, and the representation method is: schema authorinfo, separated by spaces, where schema represents verification Method, authorinfo represents verification information, common schema such as Base: authorinfo uses username + password, and is encoded with Base64. Or use Token, similar to Session.

Accept: Which serialization method to accept the data returned, expressed in MIME, used for content negotiation of the response data, can contain multiple MIME, arranged in order of priority, such as application/json, application/xml, text/html; The specific type of data that the server can return depends on the server's support. There are some standard MIMEs that can be found; sometimes we also need some customized ones. MIME, such as bson, protocolbuffer, etc., we can customize MIME and develop our own implementation on the server side, and these special extensions have corresponding extension points in ASP.NET WebApi.

Content-Type: Use a MIME representation to indicate the serialization method of the Body of the request sent. Common ones are application/json, and application/x-www-, which is most commonly used for WEB interaction. form-urlencoded, both represent the serialization method of your body part, which will appear in the request and response

I think the HTTP HEAD part is the core of the HTTP protocol There are so many places that can be configured and used, and there are too many details. The above are the most commonly used parts in my work. All the information to introduce these contents is enough to complete the whole process. This book is now available. If you are interested, you can find relevant information. In the Rest API, content negotiation often confuses people who are learning to use Rest at the beginning. Be sure to remember the functions and differences between the two headers Accept and Content-Type. Accept expresses hope. What kind of data is accepted? Content-Type indicates the encoding method of the Body in the current request. In ASP.NET WEBAPI, if there is a Content-Type in the request but no ACCEPT, the content in the Content-Type is used by default as the content negotiation for the response.

# The response part is also divided into head and body. The biggest difference between response head and request head is that the response to the first line of HTTP CODE, http code as the call of API The display of status is also very important. The most commonly used status code in REST API is generally three segments: 2XX, 4XX, and 5XX. 1XX means that the work will continue, and 3XX generally means redirection. , not used much in REST APIs. Among the three most commonly used Status segments, 2XX indicates successful execution, 4XX indicates client data errors (such as parameter verification failure), and 5XX indicates server-side processing errors, such as unhandled exceptions (such as database connection errors). , based on these status codes, the execution status of the API call can be initially judged.

      

There is a blank line (\r\n) after the header, followed by Content. There is specific business data here, which is represented by different serialization methods according to different Content-Types, such as JSON, XML, and even HTML. When you learn HTTP API, you can think that web applications are also an application of HTTP, but the interaction method generally uses application/x-www-form-urlencoded as the request and text/html as the response. RestAPI can interact with many other coding methods and supports a wider range of applications. Web application is just an application scenario that uses HTTP transmission. RestAPI and web pages cannot be separated. I think Nancy does this better than ASP.NET. Nancy does not separate RestAPI from the web page, while ASP.NET uses MVC and WEBAPI to separate the two; to request a data, I You can ask Accept to return Json data when it is application/json, and to return a web page when text/html is used; of course, cutting or merging these two application methods has its own advantages and disadvantages.

The these I wrote are too little and too few for the HTTP protocol. If you are interested, you can find relevant information by yourself. I just wrote the common parts in the Web API. Let ’s use a picture below. The picture shows you this knowledge:

The above is the detailed content of ASP.NET WebAPI pre-knowledge: HTTP and RestfulAPI. For more information, please follow other related articles on the PHP Chinese website!