Django RESTful API 设计指南

最新推荐文章于 2021-06-03 13:51:28 发布

Fe_cow丿

最新推荐文章于 2021-06-03 13:51:28 发布

阅读量250

点赞数

分类专栏： Django

本文链接：https://blog.csdn.net/Fe_cow/article/details/90753210

版权

Django 专栏收录该内容

16 篇文章 1 订阅

订阅专栏

Django RESTful API 设计指南：

REST指的是一组架构约束条件和原则。如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。
有一种统一的机制，方便不同的前端设备与后端进行通信。
下面介绍RESTful API的设计细节，探讨如何设计一套合理、好用的API。

一、协议：

API与用于的通信协议、总是使用HTTPS协议。

互联网的通信安全，建立在SSL/TLS协议之上：

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。

（2） 篡改风险（tampering）：第三方可以修改通信内容。

（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

（1） 所有信息都是加密传播，第三方无法窃听。

（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。

（3） 配备身份证书，防止身份被冒充。

二、域名：

尽量将API部署在专用域名下：

https://api.yikaoyan.com   # 将API 使用了专用的域名，进行访问(不推荐使用，会出现跨域问题)

放在主域名下：

https://yikaoyan/api/  # 将API放到主域名下

三、版本：

应该将API的版本号放入URL，这样后端服务有更新时，可以加以区分，新/老API访问地址：
```
https://yikaoyan.com/v1/
```
还有一种做法，将版本号放在HTTP头信息中，但做法不如放入URL方便与直观。

四、路径：

在RESTful架构中，每个网址代表一种资源，所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。
比如有一个数据库有一张Order表，操作这张表时，它的路径应该设计成如下：
```
https://yikaoyan.com/v1/order
```

五、HTTP动词：

对于资源的具体操作类型，由HTTP动词表示。常用的HTTP动词有下面五个(括号里对应SQL命令)。

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

还有两个不常用的HTTP 动词：

HEAD：获取资源的元数据。
OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

下面举一些栗子：

GET： /order   		列出所有的订单信息
POST： /order  		创建一个(多个)订单信息
GET： /order/ID  	通过订单ID，获取一条订单信息
PUT： /order/ID  	更新某个订单信息（提供该订单全部信息）
PATCH： /order/ID  	更新某个指定的订单信息（提供该订单的部分信息）
DELETE： /order/ID  	通过订单ID进行删除

六、过滤信息：

如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。下面是一些常见的参数。

https://yikaoyan.com/v1/order/?page=1   # 执行返回第一页码的订单数据
https://yikaoyan.com/v1/order/?page=2&page_size=10   # 执行返回第二页的订单数据，每页显示10跳数据

七、状态码：

状态码分类：

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

服务器向用户返回的状态码和提示信息，如下所示：

状态码	状态码英文名称	中文描述
100	Continue	继续。客户端应继续其请求
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议

200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求

300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy	使用代理。所请求的资源必须通过代理访问
306	Unused	已经被废弃的HTTP状态码
307	Temporary Redirect	临时重定向。与302类似。使用GET请求重定向

400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
409	Conflict	服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突
410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
412	Precondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed	服务器无法满足Expect的请求头信息

500	Internal Server Error	服务器内部错误，无法完成请求
501	Not Implemented	服务器不支持请求的功能，无法完成请求
502	Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP Version not supported	服务器不支持请求的HTTP协议的版本，无法完成处理

八、错误处理：

如果状态码是4XX，就应该向用户返回出错信息：

{
    error_code: 2001, # 除http 状态码, 自定义的错误码
    msg: '用户不存在'  # 提示这条错误信息的详解
}

九、返回结果：

针对不同操作，服务器向用户返回的结果应该符合以下规范：

# GET 请求一个列表页：  https://yikaoyan.com/v1/order/list
{
    "data":{
        "count":2,  // 共返回多少条信息
        "list":[  // 定义一个列表，作为响应信息
            {
                "返回数据"
            }, {
                "返回数据"
            }
        ],
    },
    "retCode":0,  // 响应状态码
    "retMsg":"成功 | Success"  // 响应说明
}

# GET 请求获取一条数据： https://yikaoyan.com/v1/order/1/
{
    "data":{
        "返回数据"
        }
    },
    "retCode":0,  // 响应状态码
    "retMsg":"成功 | Success"  // 响应说明
}

十、Hypermedia API：

RESTful API最好做到Hypermedia，即返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么。

# GET 请求获取一条数据： https://yikaoyan.com/v1/order/1/
{
    "data":{
        "id": 1,
        'name': '订单1'
        }
    },
    "retCode":0,  // 响应状态码
    "retMsg":"成功 | Success"  // 响应说明
}

若请求一个订单列表页的时候，需要返回的信息如下：

# GET 请求一个列表页：  https://yikaoyan.com/v1/order/list
{
    "data":{
        "count":2,  // 共返回多少条信息
        "list":[  // 定义一个列表，作为响应信息
            {
                "id":1,
                'name': '订单1'，
                'url': https://yikaoyan.com/v1/order/1/  # 点击Url的时候，就会请求上面的详情信息接口。
            }, {
                 "id":2,
                'name': '订单2'，
                'url': https://yikaoyan.com/v1/order/2/
            }
        ],
    },
    "retCode":0,  // 响应状态码
    "retMsg":"成功 | Success"  // 响应说明
}

举个请求页码的栗子：

{
    "data":{
        "count":2,
        "list":[
          {
                "id":1,
                'name': '订单1'，
                'url': https://yikaoyan.com/v1/order/1/  # 点击Url的时候，就会请求上面的详情信息接口。
            }, {
                 "id":2,
                'name': '订单2'，
                'url': https://yikaoyan.com/v1/order/2/
            }
        ],
        "links":{
            # 获取上一页,第2页的数据, 每页返回10条数据
            "previous": https://yikaoyan.com/v1/order/list/?page=2&page_size=10,
            
            # 获取下一页,第4页的数据, 每页返回10条数据
            "next": https://yikaoyan.com/v1/order/list/?page=4&page_size=10
        }
    },
    "retCode":0,
    "retMsg":"成功 | Success"
}

Fe_cow丿

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Django RESTful API 设计指南

Django RESTful API 设计指南：REST指的是一组架构约束条件和原则。如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。有一种统一的机制，方便不同的前端设备与后端进行通信。下面介绍RESTful API的设计细节，探讨如何设计一套合理、好用的API。一、协议：API与用于的通信协议、总是使用HTTPS协议。互联网的通信安全，建立在SSL...
复制链接

扫一扫

专栏目录