RESTful Six principles

1. C – S architecture

The data is stored on the Server, and the Client only needs to use it. The benefits of complete separation of the two ends make the client-side code more portable and the server-side code more extensible. Both ends develop separately without interference.

2. No state

HTTP requests are stateless. Based on the C-S architecture, each request from the client carries sufficient information for the server to recognize. Some information required by the request is contained in the QUERY parameters, header, and body of the URL. The server can correctly return the response to the client according to the various parameters of the request without saving the state of the client. Stateless features greatly improve server-side robustness and extensibility.

Of course, there are drawbacks to this total statelessness constraint. The client must determine its identity and status with the same and repeated information on each request (which is also necessary), resulting in redundancy of transmitted data, but this determination is almost negligible for performance and usage.

3. Unified interfaces

This is the core of REST architecture, where a unified interface is essential for RESTful services. The client only needs to pay attention to the implementation of the interface, the interface is more readable, easy to use personnel call.

4. Consistent data formats

The data returned by the server is either XML, Json (retrieve data), or simply a status code.

System layering: Clients are often unable to indicate whether they are directly or indirectly connected to the end server. Security policies are also considered when layering.

5. Can be cached

On the World Wide Web, a client can cache the response content of a page. Therefore, responses should be defined as cacheable either implicitly or explicitly. If they are not cacheable, clients should be prevented from responding with old or dirty data after multiple requests. Properly managed caches can partially or completely remove the interaction between client and server, further improving performance and scalability.

6. On-demand coding, customizable code (optional)

practice

Version 1.

https://example.com/api/v1/
Copy the code

2. Parameter naming conventions

For example: hump nomenclature, underline nomenclature

3. Url naming conventions

https://example.com/api/getallUsers to GET access to all https://example.com/api/getuser/1 users GET identified as 1 user information https://example.com/api/user/delete/1 GET/POST deletion marks for 1 user information https://example.com/api/updateUser/1 POST updates to 1 user information https://example.com/api/User/add POST to add a new userCopy the code

4. Unify the returned data format

For example, in json format:

// Successful response
{
  "code": 200."message": "success"."data": {
    "userName": "123456"."age": 16."address": "beijing"}}Copy the code

// Failed response
{
  "code": 401."message": "error message"."data": null
}
Copy the code