django-rest-framework框架 第一篇

本课件是为了教学任务自己写的学习django-rest-framework框架。 方便自己授课，也成为学生的复习教程。 本课程学习后：具有REST编程思维；并可以通过django及专业的django-rest框架来完成REST风格的网站后台。

RESTful架构

REST的起源 REST即表现层状态转移（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格,是一组架构约束条件和原则。

REST的名称 Fielding将他对互联网软件的架构原则，定名为REST，即Representational State Transfer的缩写。我对这个词组的翻译是"表现层状态转移"。满足REST约束条件和原则的应用程序或设计就是RESTful。REST 近年来已经成为最主要的 Web 服务设计模式。

RESTful的用处 经常用在前后端分离的开发模式中，服务端提供API服务，前端用来展示数据，直接通过ajax来沟通。

RESTful架构的资源 所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。例如:一个网页、图片、歌曲、视频、服务接口等。 每种资源对应一个特定的URI,，因此URI就成了每一个资源的地址或独一无二的识别符。

RESTful架构的表现层 "资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。 一个图片可以用jpeg格式表现，也可以用png格式来表现。

RESTful架构的表现层状态转移 资源存放在服务端，资源状态发生改变，必然也在服务端。我们可以通过HTTP协议 的请求方式不同 完成资源的状态变化。

REST API 设计

REST API 的协议 API与用户的通信协议，总是使用HTTPS协议。 REST API 的域名规范 应该尽量将API部署在专用域名之下。 https://api.example.com 如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。 https://example.org/api/ REST API 的版本位置 应该将API的版本号放入URL。 https://api.example.com/v1/ 另一种做法是，将版本号放在HTTP头信息中，但不如放入URL方便和直观。

REST API 设计

REST API 的路径url路径又称"终点"（endpoint），表示API的具体网址。 在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表名对应。一般来说，数据库中的表都是同种记录的"集合"（collection），所以API中的名词也应该使用复数。 https://api.example.com/v1/users HTTP动词 对于资源的具体操作类型，由HTTP动词表示。 常用的HTTP动词有下面五个（括号里是对应的SQL命令）。 GET（SELECT）：从服务器取出资源（一项或多项）。 POST（CREATE）：在服务器新建一个资源。 PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。 PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。 DELETE（DELETE）：从服务器删除资源。

下面是一些常见的参数。

?limit=10：指定返回记录的数量 ?offset=10：指定返回记录的开始位置。

?page=2&per_page=100：指定第几页，以及每页的记录数。

?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。

?animal_type_id=1：指定筛选条件

参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。比如，GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。

REST API中状态码（Status Codes） 服务器向用户返回的状态码和提示信息，常见的有以下一些（方括号中是该状态码对应的HTTP动词）。

REST API中错误处理（Error handling） 如果状态码是4xx，就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值即可。 { error: "Invalid API key" }

API中返回接口规范

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

GET /collection：返回资源对象的列表（数组）

GET /collection/resource：返回单个资源对象

POST /collection：返回新生成的资源对象

PUT /collection/resource：返回完整的资源对象

PATCH /collection/resource：返回完整的资源对象

DELETE /collection/resource：返回一个空文档

REST API中Hypermedia API 超媒体作为应用状态的引擎（Hypermedia as the engine of application state） RESTful API最好做到Hypermedia，即返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么。 比如，当用户向api.example.com的根目录发出请求，会得到这样一个文档。 {"link": { "rel": "collection https://www.example.com/zoos", "href": "https://api.example.com/zoos", "title": "List of zoos", "type": "application/vnd.yourformat+json" }} 上面代码表示，文档中有一个link属性，用户读取这个属性就知道下一步该调用什么API了。rel表示这个API与当前网址的关系（collection关系，并给出该collection的网址），href表示API的路径，title表示API的标题，type表示返回类型。

view编写

CBV和FBV 我们之前写过的都是基于函数的view，就叫FBV。还可以把view写成基于类的 叫CBV。 FBV（function base views） 就是在视图里使用函数处理请求。 CBV（class base views） 就是在视图里使用类处理请求。 CBV的优点: 提高了代码的复用性，可以使用面向对象的技术，比如Mixin（多继承） 可以用不同的函数针对不同的HTTP方法处理，而不是通过很多if判断，提高代码可读性