PHP Server side API Principle and Example Explanation of Interface Development

I believe everyone has done PHP request API interface to obtain data, such as Taobao API, WeChat public platform, weather inquiry, express inquiry, etc. Some need to construct sign (signature) according to signature algorithm with reference to interface documents, or set token, and then send POST request with parameters through curl to obtain return data, which is generally in json or xml format.

But now the situation is reversed. We need to develop the API interface on the PHP server side, that is, when someone requests us, we verify the legality of the request and query the data return.

In fact, this situation is used in the development of mobile phone app. Mobile phone APP applications often need to request PHP interface to obtain data, but this request 1 generally does not need to be verified. Different url is requested according to different functions, and get is usually used to transmit parameters to obtain data directly.

This article briefly talks about the server-side method of verifying the legality of requests and the way of receiving parameters.

Simple get requests such as: http://www.demo.com/api/get_cat? id=2. Requesting this URL will return 1 data, which can be obtained by whoever requests it in any programming language.

Then this is obviously not possible when the legality needs to be verified. Therefore, a secret key is needed. At this time, url is often requested by POST.

For example, there is a signature sign in the passed parameter, and the value is 98888. Of course, there are many ways to generate sign and it is impossible to be so simple. It is just written casually here, so the server side receives sign as 98888. If we agree that 98888 is legal, it can be verified that this is a legal request by judging whether sign is 98888 at this time.

However, this is too simple, and it was cracked immediately, so it is meaningless to set up this sign. Therefore, there should be a rule for generating sign. When requesting, sign is generated according to this rule, and when the server receives it, sign is also generated according to this rule. If the generated sign1 is correct, it indicates that this is a legal request. Each request is validated with sign.

There is also a kind of verification called token, which is verified at the first request, and does not need to be verified again within a certain time. This should be divided into two steps. The first step is to request the interface of token to get token, and the second step is to request the function of specific interface, which needs to bring token to pass parameters. Since the first request for token, the server first stored token and then returned, so the later request can verify whether the transmitted token exists or not.

Many interface development uses both methods to ensure privacy and security.

Another point is that the CURL module of PHP is often used to send POST requests. For example, the other party sends POST requests through curl, curl_setopt ($ch, CURLOPT_POSTFIELDS, $post_string). Here, is $post_string in the form of PHP array or json format?

If it is an PHP array, I will directly get the parameters by $_ POST ['xx']. If it is an json format, it seems that I will use file_get_contents ('php://input', 'r') to get the transmitted json data, and then parse json to get the parameters.

Under what circumstances do you use Type 2?

This has been asked on the Internet to see how everyone answers:

For PHP, JSON and arrays are sometimes really just one line of code. If I write it, I may directly reuse the first one.

I think if you want your code to be simple, you can use the second one. I remember that weixin's php and sdk seem to be similar to the second one (of course, that's xml format)

Also, if the other person uses json directly serialized by object-oriented, using json will make his code simpler by 1 point.

The first method is to transmit form form POST protocol. PHP will change PHP array into HTTP form format, which is common across languages. However, this is not the mainstream API protocol, but more like simulating submission of forms.

Most API protocols use JSON POST, and the second approach is to put JSON data in HTTP Body. It is also cross-language, but it is more friendly as API.

The first method is PHP curl directly. If the data content is not handled well, the array value sends @/xxx/xxx, and curl will send out the local files on the server, so take precautions.

x-www-form-urlencoded are RFC standards, which are not incompatible, not only across languages, but also across time and space. JSON this is in recent years to come up, is not a standard, just convenient to use.