If the rest terminal wants to maintain its own api_key, which is stored in the database, it will distribute (authorize) an api_key to the client, and then the client will exchange a token with the rest terminal using the api_key and some other conditions (such as timestamp+signature). Finally, the client will use this token to interact with the rest terminal, and you can refer to the oauth authentication of WeChat.

If the rest side does not maintain the api_key, it saves the work of distributing (authorizing) the client api_key. At this point, the client uses the parameters passed to the rest side and other conditions such as timestamp+signature to exchange tokens ... Same as above.

The above token is unique. For the request of the same client, the previous token will be invalid the next time the token is swiped.

Token itself should be maintained on the rest side, and there should be an expiration limit;

(parameter) +(api_key)+ timestamp signature is generated by an encryption algorithm (such as sha2), and the rest side can generally prevent a large part of access by checking whether the signature is legal.

As for where to put api_key or token, stateless access is common in the head (for example, angularjs project). I feel very casual here, because I can see it as long as it is intercepted, but the head can put more things for blindness.

Of course, if the token being used is intercepted, it can also be accessed at will, so it may be stronger to require https protocol plus certificate (not tried);

Generally speaking, I don't understand the higher ones. If there are any questions in the statement, please give me your comments ~