RESTful架构,就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便,因此正获得愈来愈多网站的采用。Fielding将他对互联网软件的架构原则,定名为REST,即Representational State Transfer的缩写,翻译出来就是“表层状态转化”。若是一个架构符合REST原则,就称它为RESTful架构。要理解RESTful架构,最好的方法就是去理解Representational State Transfer这个词组究竟是什么意思,它的每个词表明了什么涵义。若是你把这个名称搞懂了,也就不难体会REST是一种什么样的设计。html
REST的名称"表现层状态转化"中,省略了主语。"表现层"其实指的是"资源"(Resources)的"表现层"。django
所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它能够是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。你能够用一个URI(统一资源定位符)指向它,每种资源对应一个特定的URI。要获取这个资源,访问它的URI就能够,所以URI就成了每个资源的地址或独一无二的识别符。json
所谓"上网",就是与互联网上一系列的"资源"互动,调用它的URI。api
"资源"是一种信息实体,它能够有多种外在表现形式。咱们把"资源"具体呈现出来的形式,叫作它的"表现层"(Representation)。跨域
好比,文本能够用txt格式表现,也能够用HTML格式、XML格式、JSON格式表现,甚至能够采用二进制格式;图片能够用JPG格式表现,也能够用PNG格式表现。数组
URI只表明资源的实体,不表明它的形式。严格地说,有些网址最后的".html"后缀名是没必要要的,由于这个后缀名表示格式,属于"表现层"范畴,而URI应该只表明"资源"的位置。它的具体表现形式,应该在HTTP请求的头信息中用Accept和Content-Type字段指定,这两个字段才是对"表现层"的描述。服务器
访问一个网站,就表明了客户端和服务器的一个互动过程。在这个过程当中,势必涉及到数据和状态的变化。网络
互联网通讯协议HTTP协议,是一个无状态协议。这意味着,全部的状态都保存在服务器端。所以,若是客户端想要操做服务器,必须经过某种手段,让服务器端发生"状态转化"(State Transfer)。而这种转化是创建在表现层之上的,因此就是"表现层状态转化"。架构
客户端用到的手段,只能是HTTP协议。具体来讲,就是HTTP协议里面,四个表示操做方式的动词:GET、POST、PUT、DELETE。app
它们分别对应四种基本操做:
GET用来获取资源,
POST用来新建资源(也能够用于更新资源),
PUT用来更新资源,
DELETE用来删除资源。
综合上面的解释,咱们总结一下什么是RESTful架构:
(1)每个URI表明一种资源;
(2)客户端和服务器之间,传递这种资源的某种表现层;
(3)客户端经过四个HTTP动词,对服务器端资源进行操做,实现"表现层状态转化"。
RESTful架构有一些典型的设计误区。
一、一切皆资源,动做只是请求方式。
最多见的一种设计错误,就是URI包含动词。由于"资源"表示一种实体,因此应该是名词,URI不该该有动词,动词应该放在HTTP协议中。(get/put/post/delete)
举例来讲,某个URI是/posts/show/1,其中show是动词,这个URI就设计错了,正确的写法应该是/posts/1,而后用GET方法表示show。
若是某些动做是HTTP动词表示不了的,你就应该把动做作成一种资源。好比网上汇款,从帐户1向帐户2汇款500元,错误的URI是:
POST /accounts/1/transfer/500/to/2
正确的写法是把动词transfer改为名词transaction,资源不能是动词,可是能够是一种服务:
POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
另外一个设计误区,就是在URI中加入版本号:
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo
由于不一样的版本,能够理解成同一种资源的不一样表现形式,因此应该采用同一个URI。版本号能够在HTTP请求头信息的Accept字段中进行区分(参见Versioning REST Services)
Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0
API与用户的通讯协议,老是使用HTTPS协议。
域名
版本
路径,视网络上任何东西都是资源,均使用名词表示(可复数)
method
过滤,经过在url上传参的形式传递搜索条件状态码
错误处理,状态码是4xx时,应返回错误信息,error当作key。
{ error: "Invalid API key" }
返回结果,针对不一样操做,服务器向用户返回的结果应该符合如下规范。
GET /collection:返回资源对象的列表(数组) GET /collection/resource:返回单个资源对象 POST /collection:返回新生成的资源对象 PUT /collection/resource:返回完整的资源对象 PATCH /collection/resource:返回完整的资源对象 DELETE /collection/resource:返回一个空文档
Hypermedia API,RESTful API最好作到Hypermedia,即返回结果中提供连接,连向其余API方法,使得用户不查文档,也知道下一步应该作什么。
{"link": { "rel": "collection https://www.example.com/zoos", "href": "https://api.example.com/zoos", "title": "List of zoos", "type": "application/vnd.yourformat+json" }}
路由系统:
urlpatterns = [ url(r'^users', Users.as_view()), ]
CBV视图:
from django.views import View from django.http import JsonResponse class Users(View): def get(self, request, *args, **kwargs): result = { 'status': True, 'data': 'response data' } return JsonResponse(result, status=200) def post(self, request, *args, **kwargs): result = { 'status': True, 'data': 'response data' } return JsonResponse(result, status=200)
基于反射实现根据请求方式不一样,执行不一样的方法
原理:url-->view方法-->dispatch方法(反射执行其它方法:GET/POST/PUT/DELETE等等)