❶ restful api接口规范是什么
REST（REpresentationStateTransfer）描述了一个架构样式的网络系统，比如web应用程序。
一般依赖于HTTP认证，HTTP认证有几种：basic，digest，token，这些都有标准的实现的开源包需要主要的是这个认证的帐号跟你业务的帐户实际是不一样的。REST属于webService一种，安全是后台服务的安全，因此不需要实际的业务帐号，通常是系统keyStore证书库里的账户。
RESTFUL特点包括：
1、每一个URI代表1种资源。
2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
3、通过操作资源的表现形式来操作资源。
4、资源的表现形式是XML或者HTML。
5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。
❷ RESTful接口详解
REST是英文representational state transfer(表象性状态转变)或者表述性状态转移;Rest是web服务的一种架构风格;使用HTTP,URI,XML,JSON,HTML等广泛流行的标准和协议;轻量级,跨平台,跨语言的架构设计;它是一种设计风格,不是一种标准,是一种思想
Rest架构的主要原则：
符合REST原则的架构方式即可称为RESTful
什么是Restful:
对应的中文是rest式的;Restful web service是一种常见的rest的应用,是遵守了rest风格的web服务;rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构).
为什么会出现Restful
在Restful之前的操作：
http://127.0.0.1/user/query/1 GET 根据用户id查询用户数据
http://127.0.0.1/user/save POST 新增用户
http://127.0.0.1/user/update POST 修改用户信息
http://127.0.0.1/user/delete/1 GET/POST 删除用户信息
RESTful用法：
http://127.0.0.1/user/1 GET 根据用户id查询用户数据
http://127.0.0.1/user POST 新增用户
http://127.0.0.1/user PUT 修改用户信息
http://127.0.0.1/user DELETE 删除用户信息
之前的操作是没有问题的,大神认为是有问题的,有什么问题呢?你每次请求的接口或者地址,都在做描述,例如查询的时候用了query,新增的时候用了save,其实完全没有这个必要,我使用了get请求,就是查询.使用post请求,就是新增的请求,我的意图很明显,完全没有必要做描述,这就是为什么有了restful.
如何使用:
SpringMVC实现restful服务:
SpringMVC原生态的支持了REST风格的架构设计
所涉及到的注解:
---@RequestMapping
---@PathVariable
---@ResponseBody
HTTP相应状态码:
❸ 微信小程序上线后请求接口总是失败
本地小程序开发工具测试请求接口都很正常，使用预览和真机调试功能在手机上运行请求接口总是失败。
小程序上线后，部分手机请求接口正常，部分手机请求接口失败，将请求接口复制到谷歌浏览器中查询总是成功的。
restful 接口定义为： https://ip:port/bus/:router_name ，其中 router_name 是个变量。实际请求接口为： https://ip:port/bus/993路 ，可以看到：请求地址中的变量 router_name 被 993路 给替换了。问题就出在这里， 请求地址中含有中文 。
在 小程序开发工具 、 谷歌浏览器 和 部分请求成功的手机 上最终发出的请求都会对请求地址中的中文汉字进行编码，如下：
在 开发工具中预览功能 、 开发工具中真机调试功能 和 部分请求不成功的手机 上最终发出的请求并不会对中文进行编码，如下：
上面分析了请求接口失败是因为部分手机没有对请求地址中的中文进行编码，解决方法为利用 js 自带的 api encodeURIComponent() 处理。
有一点需要注意：不能对整个请求地址进行编码，那么的话会对所有除字母、数字以外的符号进行编码，会变成下面这样，实际请求中仍然会报错。
在处理 restful 接口过程中，有一步用具体指（如： 991路 ）替换请求地址中的变量（如： https://ip:port/bus/:router_name 中的 :router_name ），此时先对 991路 进行编码再替换变量值即可。
❹ 如何理解rest和restful，什么是restfulAPI
简单理解一
就是用URL定位资源，用HTTP描述操作。
简单理解二
URL定位资源，用HTTP动词(GET,POST,DELETE,DETC)描述操作。
官方定义
一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
以web开发举例
在设计web接口的时候，REST主要是用于定义接口名，接口名一般是用名次写，不用动词，那怎么表达“获取”或者“删除”或者“更新”这样的操作呢——用请求类型来区分。
比如，我们有一个students接口，对于“学生”我们有增删改查四种操作，怎么定义REST接口？
增加一个学生，uri: http://testcode.com/school/students 接口类型：POST
删除一个朋友，uri: http://testcode.com/school/students 接口类型：DELETE
修改一个朋友，uri: http://testcode.com/school/students 接口类型：PUT
查找朋友，uri: http://testcode.com/school/students 接口类型：GET
上面我们定义的四个接口就是符合REST协议的，请注意，这几个接口都没有动词，只有名词students，都是通过Http请求的接口类型来判断是什么业务操作。
举个反例
uri: http://testcode.com/school/addStudents 该接口用来表示增加学生，这就是不符合REST协议的接口。
建议
用HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误，403表示Bad Request等。(反例：传统web开发返回的状态码一律都是200，其实不可取。)
REST风格接口意义
前后端分离。前端拿到数据只负责展示和渲染，不对数据做任何处理。后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，在web，ios，android三端都可以用相同的接口，节约开发成本以及便于同一调试。
❺ django-restful:与前端vue接口对接
category 与vue 接口对接
首先是需要把所有的category的内容取出来
由于前端vue展示category是分级的
一级 二级 三级 这样展示的
所以我们需要把三个内容都拿出来
但是首先需要取出第一级 然后第一级镶嵌了第二级，然后第二级镶嵌第三季 ，就跟上面goods中显示外键的category的内容一样
我们还是需要写serializer
这样就是一级 镶嵌二级 二级镶嵌三级
但是这里有一个问题不要搞错了 这三个类的位置不能弄错了
因为一级是调用二级 所以二级一定是先写好了的
所以二级一定在一级上面 同理 三级要在二级上面
然后就是view
在过滤中加上category_type = 1 这样就可以直接显示第一大类 然后第一大类中有第二小类 这样更有层次感 如果直接一下子全部取出来 就不好分辨了
同时我们还要处理取出某个单一的信息
所以 我们继承了mixins.RetrieveModelMixin 这个类，这是一个显示详情的类
例如显示某个动物园的某个动物那样
/zoos/id
这样的url
同样这样写了 我们就直接只配置category的url就够了
就不用考虑 后面的id是否还需要配置一个url 这些都不用考虑了，因为我们继承了 viewset这个类
这些问题他都帮我们解决了
这样处理我们后端就能看见了
但是这样处理了 前端对接时 会发现 无法显示
因为有一个跨域问题
这个问题前后端 都可以独自解决 这里学习的是后端，所以讲一下后端的做法
就是修改服务端
在github上搜索django-cors-headers就可以找到这个信息
同样里面介绍如何使用
安装
pip install django-cors-headers
然后settins中INSTALLED_APPS配置和settings中MIDDLEWARE配置
这里要注意 MIDDLEWARE配置中
'corsheaders.middleware.CorsMiddleware',
'django.middleware.common.CommonMiddleware',
这两个必须放在
'django.middleware.csrf.CsrfViewMiddleware',
这个的前面 不然会报错
同时还要配置
CORS_ORIGIN_ALLOW_ALL = True
允许跨域访问 它默认是False
这样前端就可以正常显示了
为什么会产生跨域访问
因为vue中api配置的中 我们调试数据 不可能把所有的host 都修改了 有一些是线上数据 我们调试的是本地的一部分数据 所以要重新定一个localhost
修改部分 host的链接
这样就导致了跨域 本身使用的是一个线上host端口，但是数据中有一部分是请求的是本地host端口 导致了跨域访问
❻ RESTful 接口教程
我们现实生活中的协议是指相互遵守的规定，单方面违背，协议不成立。
而在互联网交互的过程中，也存在这许多协议，例如 FTP、HTTP、STMP、TCP/IP 等。
而 HTTP 协议则是 web 服务器 和 web 客户端 达成的一种可靠的数据传输协议，通过 HTTP 可以从遍布全世界的 Web 服务器上将 JPEG 图片，HTML 页面，文本文件，MPEG 电影，WAV 音频文件和其他资源信息块迅速、便捷、可靠地搬移到人们桌面上的 Web 浏览器上去。它能够确保数据在传输的过程当中不会损坏或者产生混乱。这样，对用户来说是个好事，同样对 Internet 应用的开发人员来说也是一件好事。因为我们在开发过程中也不需要担心自己的页面和数据会在传输过程中发生破坏和畸变了。
Web 内容都是 存储在 Web 服务器 上的。Web 服务器所使用的是 HTTP 协议，因此经常会被称为 HTTP 服务器。这些 HTTP 服务器存储了因特网中的数据，如果 HTTP 客户端发出请求的话，它们会提供数据。客户端向服务器发送 HTTP 请求，服务器会在 HTTP 响应中回送所请求的数据。
那么一次请求和响应的过程中发生了什么？
web 服务器是 web 资源的宿主 ，而 web 资源就是我们常见的 web 内容的源头，最简单的 web 资源就是我们服务器中的静态文件：文本文件，HTML 文档，JPEG 图片文件，AVI 文件等等。
当然 web 资源也可以是动态生成的，类似搜索引擎生成的页面，QQ 空间的动态等，总之，所有类型的内容来源都是资源。
因特网上有数千种不同类型的数据类型，HTTP 在传输的过程中为每个传输的数据都打上了名为 MIME 类型的数据类型标签，描述并标记多媒体内容。
web 浏览器请求一个网站的时候往往会发布 多个 HTTP 请求 ，比如我们在浏览一个具有丰富图片的的 web 页面的时候，浏览器会执行一次 HTTP 请求来获取描述页面布局的 HTML，然后发布另外的请求来获取每个嵌入式的图片，这些图片甚至可能位于不同的服务器上。因此，一个 web 页面通常不是单个资源，而是一组资源的集合。
web 服务器会为所有的 HTTP 对象数据附加一个 MIME 类型 ，当浏览器从服务器中取回一个对象的时候，会查看相关的 MIME 类型。看看它是否知道应该如何处理这个对象。对象的类型写在响应的 content-type 头 中；同样，请求的时候浏览器也会告知服务器请求数据类型。
常见的 MIME 类型：
以 application 开头的媒体格式类型：
MIME 参考手册： W3school MINE类型
大部分 URL 都遵循一种标准格式， 这种格式包含三个部分。
URI = Uniform Resource Identifier 统一资源 标志符
URL = Uniform Resource Locator 统一资源 定位符
URN = Uniform Resource Name 统一资源 名称
翻译成人话: URI 是抽象的定义，不管用什么方法表示，只要能定位一个资源，就叫 URI，本来设想的的使用两种方法定位。
1）URL 用地址定位
2）URN 用名称定位
举个例子：去村子找个具体的人（URI）。如果用地址：某村多少号房子第几间房的主人就是 URL， 如果用身份证号 + 名字，去找就是 URN 了。
目前 WEB 上就 URL 流行开了，平常见得 URI 基本都是 URL。
1）HTTP 和 HTTPS 的相同点
2）HTTP 和 HTTPS 的不同之处
3）如何选择 HTTP 和 HTTPS 协议
HTTP 支持几种不同请求和命令，这些命令被称为 HTTP 方法，每条 HTTP 请求报文都包含一个方法。 这个方法会告诉服务器要执行什么动作（获取一个 Web 页面、发送一段信息、删除一个文件等）。
请求方法如下：
状态码分成如下几个系列：
常见的 HTTP 状态码：
从 Web 客户端发往 Web 服务器的 HTTP 报文称为请求报文（request message）。从服务器发往客户端的报文称为响应报文（response message）。
HTTP 报文包括以下三个部分:
以上内容复制自： http://www.cnblogs.com/Joans/p/3956490.html
使用火狐和 chrome 浏览器打开一个网页，找到其中一个网络请求查看报文。
1）协议
2）域名
3）接口版本控制规范
格式规范如下：
更新版本后可以使用 v2、v3 等依次递加。
4）接口路径规范
格式规范如下：
5）接口命名规范
格式规范如下：
6） HTTP 请求方法
格式规范如下：
GET https://api.xxxxx.com/v1/zoos ：列出所有动物园
POST https://api.xxxxx.com/v1/zoos ：新建一个动物园
GET https://api.xxxxx.com/v1/zoos/ID ：获取某个指定动物园的信息
PUT https://api.xxxxx.com/v1/zoos/ID ：更新某个指定动物园的信息（提供该动物园的全部信息）
PATCH https://api.xxxxx.com/v1/zoos/ID ：更新某个指定动物园的信息（提供该动物园的部分信息）
DELETE https://api.xxxxx.com/v1/zoos/ID ：删除某个动物园
GET https://api.xxxxx.com/v1/zoos/ID/animals ：列出某个指定动物园的所有动物
DELETE https://api.xxxxx.com/v1/zoos/ID/animals/ID ：删除某个指定动物园的指定动物
注意：修改有两个方法 PUT 和 PATCH。
假设 URL 位置有一组数据 UserInfo，包括 UserID、UserName 等 20 个字段
需求：用户修改了 UserName，其他不变
• 采用 PATCH，仅向 URL 提交 UserName 的局部更新请求
• 采用 PUT，必须将所有 20 个字段一并提交到 URL，未提交字段被删除
PATCH 的最主要好处：节省网络带宽
7）接口信息过滤
格式规范如下：
?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 的含义是相同的。
8）请求参数规范
9）接口返回数据
格式规范如下：
status:：接口的执行状态
data：接口的主数据
msg：返回成功或者失败的错误信息
返回数据中的状态码、状态信息，常指具体的业务状态，不建议和 HTTP 状态码混在一起。HTTP 状态，是用来体现 HTTP链路状态情况，如：404-Not Found。HTTP 状态码和 JSON 结果中的状态码，并存尚可，用于体现不同维度的状态。
简单的功能如下：
这里不牵扯到任何 Python 和 Pycharm 的教学，不会的童鞋挪步 Python 开发教程。
参考新浪开放平台 https://open.weibo.com ，基本是国内最为标准的 API 文档之一。