In order to facilitate you to quickly test your interface, you can send your request information to this site. As long as you send it in the format of this site, you can directly jump to the request page of this site, saving you the trouble of developing your own request. !
The address provided by this site: http://coolaf.com/tool/gp, support get request, pass the parameters to this site in your webpage
The url will automatically fill in the request box of this site, which is convenient for you to test directly. The parameter description is as follows:
u: The url you requested, required
m: request method, default post. Others are: get, put, delete, head, trace, patch, options
p: the post parameters you requested, optional
c: The cookie you requested, the format is like the filling method of this site page, optional
h: The header you requested, the format is like the filling method of this site page, optional
px: Use proxy ip, format 10.10.10.10: 8080, optional
All the above parameters need to be encodeURIComponent
Brief description of this tool:
1. This online tool supports interface http post, get, put, delete, head, trace, options, patch and other requests, and supports requests with cookie header and ip proxy
2. Can generate api interface documents, this site also provides api interface stress test and websocket test. 2. When accessing the interface to be logged in, you can manually fill in the cookie. Or visit this interface domain name in Google Chrome, press F12, under network,
, directly copy and fill in the cookie of this tool. You can visit with cookies, no need to fill in manually
3. The header can be entered manually (custom header information). You can also get the header information in the network of the browser and fill it directly into the header input box of this tool.
In the vernacular about http request:
To test and use the http interface, we must first understand what an http request is:
Generally speaking, http request is to send the client's things to the server through the http protocol, and the server parses the client's sent according to the definition of the http protocol.
The get and post request parameters are commonly used in http requests. The get parameters are spliced at the back of the url, and the domain name and parameters are connected with "?" to form a get request.
For example: http://coolaf.com?a=b&c=d, after the question mark is the get request parameter, the post request will not be seen in the url, it will be placed in http
In the body of the request, functions are encapsulated in all major languages, and the post request parameters are parsed in the body. What does the post parameter look like? it can be
Any form, the common key=value form is the same as the get request form "a=b&c=d". In addition, json and xml formats are also common. this
Some formats will be affected by Content-Type when they are delivered. Different Content-Type delivery formats are different, and the server will be based on
Content-Type analyzes the corresponding format. The client and server use these protocols to distinguish what format is being delivered. Must understand
Common Content-Type, please refer to the above Content-Type link description for more.
Content-Type: application/x-www-form-urlencoded, similar to form forms and get and post requests.
format such as "a=b&c=d", the server will automatically parse
Content-Type: application/json If you want to send json format, you need to add this Content-Type in the request header
type, the acceptance of this form of server is not the same, generally it will not be parsed into the post request, generally it needs to be obtained by reading the body stream.
The above are two common transmission formats. Sometimes when we write the code ourselves, we don’t need to write it. That’s because some of the libraries have been added automatically, so
You don’t need to add it yourself. Content-Type is very important. It affects the format you deliver.
Also pay attention to in the http request is the header, which is divided into request header and response header, request header
It is sent when the client requests it, telling the server you the situation of the client, how the server needs to return to you, for example, whether to compress
(Accept-Encoding: gzip, deflate, sdch) This is to tell the server that I support these kinds of compression. When you return
Later, you can choose a kind of data compression, I can unlock it. There are also whether to cache, accepted languages, User-Agent, referer, etc.,
The cookie is also placed in the request header and passed to the server to enable login. So the request header tells
What do you have on the server side or the parameters to pass, the above are all defined by the http protocol, and everyone can parse it according to this rule. In addition,
The header can be customized, you can add any variable to it. So the information in the header can be modified arbitrarily and sent to
On the server side.
The response header is relative to the request header, which is the information that the server gives to the client. Some are based on the client
response to the demand, some server tells the client some other information, for example, request protocol, request status code, whether to cache,
Setting the cookie is also returned in the response header, and the browser will set it in the browser when it receives it.
There are so many vernaculars. Any mistakes or problems can be discussed in the group. Learning is endless. http is not magical. Make more use of the browser's f12,
Look at the network, over time, there will be unexpected effects! ! !