通俗直白讲:REST是一种编写风格,一种API接口规范。它的风格就是将对象(如学生)的状态(如增删改查,API接口版本号等等)通过其他方式传递,API的接口地址突显出描述的对象。
--
==
REST/RESTful大概就是以下的实现步骤
1. 用URL/URI来表示Object 例如 http://www.example.com/order/111111 来表示一个订单
2.用标准的HTTP协议来完成逻辑操作,通常有以下几个对应 HTTP Get来获得一个订单的内容,HTTP Put来更新一个订单, HTTP Post来新增一个订单, HTTP Delete来删除一个订单。
3. 无状态,一般指的是服务器端不保留任何操作和事务的状态,也就不存在类似回滚的操作
--
具体风格样式可以参考以下
RESTful风格Api
1.RESTful api接口规范:
(1)协议
API与用户的通信协议,总是使用HTTPs协议,确保交互数据的传输安全。
(2)域名应该尽量将API部署在专用域名之下。
https://api.example.com
如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下。
https://example.org/api/
(3)api版本控制
应该将API的版本号放入URL。
https://api.example.com/v{n}/
另一种做法是,将版本号放在HTTP头信息中,但不如放入URL方便和直观。Github采用这种做法。
采用多版本并存,增量发布的方式。
v{n} n代表版本号,分为整形和浮点型;
整形的版本号: 大功能版本发布形式;具有当前版本状态下的所有API接口 ,例如:v1,v2;
浮点型:为小版本号,只具备补充api的功能,其他api都默认调用对应大版本号的api 例如:v1.1 v2.2
(4)API 路径规则
路径又称"终点"(endpoint),表示API的具体网址。在RESTful架构中,每个网址代表一种资源(resource),所以
网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记
录的"集合"(collection),所以API中的名词也应该使用复数。
举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。
https://api.example.com/v1/products
https://api.example.com/v1/users
https://api.example.com/v1/employees
(5)HTTP请求方式
对于资源的具体操作类型,由HTTP动词表示。
常用的HTTP动词有下面四个(括号里是对应的SQL命令)。
GET(SELECT):从服务器取出资源(一项或多项)。
POST(CREATE):在服务器新建一个资源。
PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
DELETE(DELETE):从服务器删除资源。
下面是一些例子。
GET /product/ID/purchase :列出某个指定商品的所有投资者
GET /product/ID/purchase/ID:获取某个指定商品的指定投资者信息
GET /product:列出所有商品
GET /product/ID:获取某个指定商品的信息
POST /product:新建一个商品
PUT /product/ID:更新某个指定商品的信息
DELETE /product/ID:删除某个商品
(6)过滤信息
如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果。
下面是一些常见的参数。
?limit=10:指定返回记录的数量
?offset=10:指定返回记录的开始位置。
?page=2&per_page=100:指定第几页,以及每页的记录数。
?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序。
?producy_type=1:指定筛选条
(7)API 传入参数
参入参数分为4种类型:
(a)地址栏参数
restful 地址栏参数 /api/v1/product/122 122为产品编号,获取产品为122的信息
get方式的查询字串 见过滤信息小节
(b)请求body数据
cookie
request header
cookie和header 一般都是用于OAuth认证的2种途径
(c)返回数据
只要api接口成功接到请求,就不能返回200以外的HTTP状态。
为了保障前后端的数据交互的顺畅,建议规范数据的返回,并采用固定的数据格式封装。
接口返回模板:
{
status:0,
data:{}||[],
msg:’’
}
status:接口的执行的状态
=0表示成功
<0 表示有异常=""
Data:接口的主数据,可以根据实际返回数组或JSON对象。
Msg:当status!=0 都应该有错误信息。
==
==
REST(英文:Representational State Transfer,简称REST)
representational state transfer
表述性状态转移;表现状态传输
representational
英 [ˌreprɪzenˈteɪʃnl] 入哎普神提手 。.美 [ˌrɛprɪzɛnˈteʃənəl, -zən-]
adj.
代表性的,具象派的
在目前主流的三种Web服务交互方案中,
REST相比于SOAP(Simple Object Access protocol,简单对象访问协议)
以及XML-RPC更加简单明了,
无论是对URL的处理
还是对Payload的编码,
REST都倾向于用更加简单轻量的方法设计和实现。
值得注意的是REST并没有一个明确的标准,
而更像是一种设计的风格。
三种Web服务交互方案:
REST(representational state transfer ,表述性状态转移)
SOAP(Simple Object Access protocol,简单对象访问协议)
XML-RPC
--
REST是一种风格样式。 没有统一标准。是一个概念。
REST用于 web 服务和动态 Web 应用程序的多层架构
可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。
--
在 REST 样式的 Web 服务中,每个资源都有一个地址。、
资源指的是 如:应用程序对象、数据库记录、算法等等。
资源本身都是方法调用的目标,方法列表对所有资源都是一样的。
这些方法都是标准方法,包括 HTTP GET、POST、PUT、DELETE,还可能包括 HEAD 和 OPTIONS。
在 RPC 样式的架构中,关注点在于方法,而在 REST 样式的架构中,关注点在于资源。
==
这样的概念 解释还是太虚。
应该有具体的内容 例子。
举例来说,某个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
==