Shulou(Shulou.com)06/03 Report--

This article is to share with you the content of the sample analysis of WebAPI pre-knowledge HTTP and RestfulAPI in ASP.NET. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

A basic understanding of the HTTP protocol is the basis for understanding and using RestFul-style API. After understanding these basics, it is easy to use various RestFul development frameworks. I started to use WebApi because of the lack of understanding of these knowledge, feel that it is not easy to use, until familiar with the knowledge of these HTTP, use WebApi development feel comfortable, my understanding, RestFul style API is good support for the HTTP protocol, the realization of HTTP complete semantic style of API.

Before I introduce this knowledge, I need to highlight a misunderstanding that many people have: the predicates and data delivery methods of HTTP. The HTTP protocol that most people come into contact with and use is in the process of website writing. In general WEB applications, we only use GET and POST predicates, and the other predicates are not applicable. Under this habit, many people have a few strange perceptions: HTTP protocol is only suitable for website development, and HTTP has only two predicates: GET/POST,HTTP call data transfer is only carried out in the form of form KLV. In this understanding, RestApi developed in this style will often be irrelevant, and the use of ASP.NET WebAPi will also seem irrelevant and troublesome. First of all, we have to realize that the data interaction of the website is just a scenario used by HTTP, and HTTP can transmit various forms of data.

Let's 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 route. The most commonly used predicates are: POST\ DELETE\ PUT\ GET. These four predicates correspond to the four actions of "add, delete, change, and check" (POST and PUT, who is adding and who is changing different materials are always different, I am actually a little confused. It is defined that PUT is an idempotent operation, but POST is not, so PUT is more focused on modification and POST is more emphasis on increment. The most commonly used predicates are these four, and there are other predicates that have different semantics:

HEAD: only the corresponding headers are returned, excluding Body

TRACE: diagnosing the data transfer process

OPTIONS: request the Web server to inform it of the various features it supports

There are other predicates that can be queried if necessary, but are not commonly used.

Where GET,DELETE does not contain BODY,PUT,POST can contain BODY. If a predicate contains operations other than semantics, for example, the operation of deleting resources with BODY,POST in GET is also allowed, which is called predicate overloading. Although HTTP can support predicate overloading, it is not recommended because it does not conform to the 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 a set of operations:

GET www.example/person/1 is to obtain the information of a user whose ID is 1.

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

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

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

HTTP version:

At present, HTTP1.0 and HTTP1.1 protocols are mainly used, while HTTP2.0 protocols are being popularized and not used very much. There is little difference between HTTP1.0 and HTTP1.1, and the difference does not have much impact on RestFul. For specific differences, you can consult the relevant documents.

This is the first line of the HTTP, followed by a\ r\ nline wrap, followed by the HTTP HEAD section, where HTTP HEAD describes the HTTP request and response. I think HTTP HEAD is the most important part of the HTTP protocol, it contains coding, BODY length, content negotiation and other information, you can also include some custom information. Let me introduce you to some HEAD commonly used in RestFul API:

User-Agent: user agent, which is the client that sent the request, such as IE, Chrome, Fiddler, etc.

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

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

Accept: data returned by which serialization method is accepted, expressed in MIME. For content negotiation of response data, it can contain multiple MIME, arranged in order of priority. For example, application/json,application/xml,text/html; specific server can return what type of data needs to be supported by the server. There are some standard MIME that can be found. Sometimes we also need some custom 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 to indicate the serialization of the Body of the request sent, such as application/json, and application/x-www-form-urlencoded, which is most commonly used in WEB interactions, all indicate the serialization of your body part, which will appear in both the request and response.

The HTTP HEAD part, I think, is the core part of the HTTP protocol, in which there are too many places to configure and use, and there are too many details. The above is my list of the most commonly used parts in my work. All the materials introducing these contents are enough to complete a book. If you are interested, you can find relevant materials. In Rest API, content negotiation often confuses people who learn to use Rest at the beginning. It is important to remember the role and difference between the two headers of Accept,Content-Type. Accept indicates what kind of data you want to accept, and Content-Type represents how Body is encoded 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 as the content negotiation of the response by default.

The response part is also divided into the header and the Body. The biggest difference between the response header and the request header is that there is a HTTP Code,HTTP Code in the first line of the response as a display of the call status of API, which is also very important. The most commonly used status code in REST API is generally 2XXMagitem4XX 5XX, while 1XX indicates that the work needs to continue. 3XX generally means redirection, which is not used much in REST API. In the three most commonly used Status segments, 2XX indicates successful execution, 4XX indicates client-side data error (for example, parameter verification fails), and 5XX indicates server-side processing error, such as unhandled exception (such as database connection error). Based on these status codes, you can initially judge the execution status of API call.

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

What I have written is really too little for the HTTP protocol. If you are interested, you can find the relevant information on your own. I just wrote out the commonly used parts of WEB API. Let's use a picture to show you this knowledge:

Thank you for reading! This is the end of this article on "sample Analysis of WebAPI pre-knowledge HTTP and RestfulAPI in ASP.NET". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it out for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.