信息流

对于后端开发者，本质上就是提供URL给前端开发者调用并返回相应的数据。

前后端配合

• 数据传输用XML格式？JSON格式？
• 出现错误时，错误信息有谁来提供？ ```json 方案1：错误时后端返回错误信息，前端只做呈现即可。
  {
  code:40001,

   error:"xxx错误"    

  }

方案2：错误时后端返回错误码，前端根据错误码的对应关系呈现。
{
code:40001
}

<a name="DoIeR"></a>
# restful接口初识
restful是主流的一套API规范，企业进行前后端分离开发一般都会遵循它，他定义了很多规范的条款。<br />例如：如果现在让大家来开发一个对 **用户表** 进行增删改查的接口，在不了解restful规范前， 大家一定会这样来搞：
```json
接口：/users/list/            用户列表
接口：/users/add/            添加用户
接口：/users/detail/(\d+)    用户详细信息
接口：/users/edit/(\d+)    更新用户
接口：/users/del/(\d+)        删除用户

很早之前开发者们也确实都是这么干的，直到后来有人提出了 restful API规范（包含了很多规定），如果按照这个规范来开发上述的功能的话：

接口：/users/            方法：GET     =>   用户列表
接口：/users/            方法：POST    =>   添加列表
接口：/users/(\d+)/    方法：GET     =>   获取单条数据
接口：/users/(\d+)/    方法：DELETE  =>   删除数据
接口：/users/(\d+)/    方法：PUT     =>   更新数据

感觉也没什么了不起嘛，但是规范的好处就是：
1.对于前端和后端的开发效率都会有很大的帮助，不用再做很多无效的沟通了。
2.后端看后端的代码也方便了。

域名

对于后端API接口中要体现API标识，例如：

• https://**api**.example.com
• https://www.example.com/api/

版本

对于后端API接口中要体现版本，例如：

- http://api.example.com/v1/
- http://api.example.com/?version=v1
- http://v1.example.com/
- http://api.example.com/
  请求头：Accept: application/json; version=v1

路径

restful API这种风格中认为网络上的一切都称是资源，围绕着资源可以进行 增删改查等操作。
这些资源，在URL中要使用名词表示（可复数），围绕着资源进行的操作就用Method不同进行区分。

https://api.example.com/v1/person
https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees

请求方法

根据请求方法不同进行不同的操作。

GET        在服务器取出资源（一项或多项）
POST    在服务器新建一个资源
PUT        在服务器更新资源（客户端提供改变后的完整资源）
PATCH    在服务器更新资源（客户端提供改变的属性）
DELETE    在服务器删除资源

例如：

https://api.example.com/v1/users
https://api.example.com/v1/users/1/
接口：/users/            方法：GET     =>   用户列表
接口：/users/            方法：POST    =>   添加用户
接口：/users/(\d+)/    方法：GET     =>   获取单条数据
接口：/users/(\d+)/    方法：DELETE  =>   删除数据
接口：/users/(\d+)/    方法：PUT     =>   更新数据
接口：/users/(\d+)/    方法：PATCH   =>   局部更新

搜索条件

在URL中通过参数的形式来传递搜索条件。
[https://api.example.com/v1/users](https://api.example.com/v1/users)

https://api.example.com/v1/zoos?limit=10                指定返回记录的数量
https://api.example.com/v1/zoos?offset=10                指定返回记录的开始位置
https://api.example.com/v1/zoos?page=2&per_page=100        指定第几页，以及每页的记录数
https://api.example.com/v1/zoos?sortby=name&order=asc    指定返回结果按照哪个属性排序，以及排序顺序
https://api.example.com/v1/zoos?animal_type_id=1        指定筛选条件

返回数据

针对不同操作，服务器向用户返回的结果结构应该不同。

https://api.example.com/v1/users
https://api.example.com/v1/users/2/

一般在实际的开发过程中会对上述返回数据进行补充和完善，例如：每次请求都返回一个字典，其中包含：

• code，表示返回码，用于表示请求执行请求，例如：0表示请求成功，1003表示参数非法，40009数据量太大等。
• data，表示数据
• error，错误信息

  {
    code:0,
    data:[ {id:1,name:"沐风"},   {id:1,name:"日天"}  ]
  }

  {
    code:41007,
    error:"xxxxx"
  }

状态码

后端API在对请求进行响应时，除了返回数据以外还可以返回状态码，来表示请求状况。
状态码可以表示的情况太少，一般用code。

from django.urls import path, include
from app01 import views
urlpatterns = [
    path('users/', views.users),
]

from django.http import JsonResponse
def users(request):
    info = {
        "code": 1000,
        "data": {"id":1,"name":"沐风"}
    }
    return JsonResponse(info, status=200)

200 OK - [GET]：服务器成功返回用户请求的数据
201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。
202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
204 NO CONTENT - [DELETE]：用户删除数据成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作。
401 Unauthorized - [*]：表示用户未认证（令牌、用户名、密码错误）。
403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。
404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作。
406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。
更多看这里：http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

错误处理

错误处理，状态码是4xx时，应返回错误信息，error当做key。
建议使用以下格式，特别是code关键字。

{
      code:400444,
    error: "Invalid API key"
}