These core knowledge points must be mastered in front-end and back-end communication!

What is restful?

Restful is the most popular interface design specification at the moment. It is a specification that both front-end and back-end must know. This specification defines that in interface development, in each process,

protocol

client should use when communicating with the back-end service through the API. The HTTPS protocol

domain name

API should be deployed under a dedicated domain name and should be kept as simple as possible. If you are sure that the API is very simple and will not be further expanded, you can consider placing it under the main domain name. Here are two common URL root examples:

• api.example.com/* A separate subdomain name is used to access the interface
• example.com/api /* All APIs in a single space

version (Versioning)

must remain backward compatible. You must introduce new versions of APIs while ensuring that old version APIs are still available. Therefore, a version support

address (path) should be provided for the specific URL of the routing (router)

API.

• The naming of the URL must be all lowercase
• . The naming of the resource (resource) in the URL must be a noun, and must be in plural form.
• Restful type URLs must be used first
• . It must be an easy-to-read
• URL and must not expose the server architecture.

As for whether the URL must use hyphens (-) or underscores (_), there is no hard and fast rule, but it must be consistent with a style based on the team's situation

• https://api.example. com/zoos
• https://api.example.com/animals
• https://api.example.com/zoos/{zoo}/animals
• https://api.example.com/animal_types
• https://api.example. com/employees

verb (request method method)

is a specific operation type for resources, represented by HTTP verbs. There are five commonly used HTTP verbs (the corresponding SQL commands are in brackets).

• GET (SELECT): Retrieve resources (one or more items) from the server.
• POST (CREATE): Create a new resource on the server.
• PUT (UPDATE): Update the resource on the server (the client provides the complete resource after the change).
• PATCH (UPDATE): Update in the server update resource (client provides changed attributes) part.
• DELETE (DELETE): Delete resources from the server.

url parameters

All URL parameters must be in all lowercase and must use underscore type parameter form. The paging parameters must be fixed to page and page_size.

The response (Response)

must select an appropriate HTTP status code.
Data must be returned in JSON format.
All errors must be formatted uniformly.

The common status code

• 1xx means that the request has been accepted and needs to continue processing.
• 2xx generally does not appear in the API. The request has been successful, and the response header or data body expected by the request will be returned with this response
  • . 200. The server successfully returns the data requested by the user.
  • 201 User creates a new or Modify data successfully
  • 202 means that a request has entered the background queue (there is no return value if successful, it is asynchronous)
  • 204 Delete successfully
• 3xx Redirect
• 4xx Error caused by client reasons
  • 404 The requested interface does not exist, error type (the request address is wrong)
  • 401 The user is not
  • logged in 403 The user is logged in, but does not have permission to access
  • 422 Client parameter error, verification error
  • 429 Request limit exceeded
• 5xx Error caused by server-side reasons
  • 500 The server encountered an unexpected situation, which caused it to be unable to complete the request Processing, the server code reports
  an
  • error 503. The server is under maintenance.
  • 504 Timeout call

error format

'message' => ':message', // Detailed description of the error 'errors' => ':errors', // Detailed error description of the parameters, 422 and other statuses provide 'code' => ':code', // Business-defined exception code 'status_code' => ':status_code', // http status code 'debug' => ':debug', // debug Information, non-production environment provides

what is the message?

HTTP messages are used to exchange information when HTTP requests and responses. Messages that flow into the server from the client

are divided into two categories: request messages

and response messages. The basic message structures of request and response messages are the same, and they are composed of three parts:

• Starting line: perform the processing on the message Description
• header: some attributes
• Body: data [optional]

axios

compatible browser and node server create XMLHttpRequests from the browser
Creating http requests from node.js

supports Promise API
Supports interception of requests and responses, conversion of request data and response data, cancellation of requests, automatic conversion of JSON, data client support for defense against XSRF

, come on, strangers! (I am no stranger to coming and going, I hope it will be helpful to you)

The above are these core knowledge points, which must be mastered in front-end and back-end communication! For more details, please pay attention to other related articles on the php Chinese website!