浅谈RESTful

最新推荐文章于 2022-11-07 14:40:25 发布

Elinice

最新推荐文章于 2022-11-07 14:40:25 发布

阅读量165

点赞数

分类专栏：转载优秀博文文章标签： Restful

转载优秀博文专栏收录该内容

4 篇文章 0 订阅

订阅专栏

小白学习RESTful。
参考资源：
https://www.cnblogs.com/binlin1987/p/6971808.html
https://www.cnblogs.com/rgcLOVEyaya/p/RGC_LOVE_YAYA_617days.html

什么叫restful：

REST的名称"表现层状态转化"中，省略了主语。“表现层"其实指的是"资源”（Resources）的"表现层"。

所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

GET /tickets # 获取ticket列表
GET /tickets/12 # 查看某个具体的ticket
POST /tickets # 新建一个ticket
PUT /tickets/12 # 更新ticket 12.
DELETE /tickets/12 #删除ticekt 12

RESTful架构优点：

1、前后端分离，减少流量
2、安全问题集中在接口上，由于接受json格式，防止了注入型等安全问题
3、前端无关化，后端只负责数据处理，前端表现方式可以是任何前端语言（android，ios,html5）
4、前端和后端人员更加专注于各自开发，只需接口文档便可完成前后端交互，无需过多相互了解
5、服务器性能优化：由于前端是静态页面，通过nginx便可获取，服务器主要压力放在了接口上

RESTful架构设计原则

1、在接口命名时应该用名词，不应该用动词，因为通过接口操作到是资源。
2、在url中加入版本号，利于版本迭代管理更加直观

https://www.rgc.com/v1/

3、对于资源的操作类型应该是通过http动词表示。

GET /zoos：列出所有动物园
POST /zoos：新建一个动物园
GET /zoos/ID：获取某个指定动物园的信息
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息
DELETE /zoos/ID：删除某个动物园
GET /zoos/ID/animals：列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

4、排序规则：默认时升序，‘-’为降序;多个排序规则时以逗号间隔组合。使用sort查询参数限制

GET /tickets?sort=-time,created_at
//优先以time倒序显示，其次以created_at正序显示

5、限制返回值的字段域：明确指定输出字段列表，用于控制网络带宽和速度。使用fields查询参数来限制。

GET /tickets?fileds=id,subject,customer_name,time&sort=-time
//返回参数列表为id,subject,customer_name,time，并且以time字段倒序显示

6、HTTP Method分别对于资源的CURD操作

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

保证 POST，PUT，DELETE,PATCH操作幂等性。

7、使用SSL(Secure Sockets Layer 安全套接层)
8、参数和url采用蛇行命名方式。如：updated_time
9、服务器请求和返回的数据格式，应该尽量使用JSON，避免使用XML。在 request中的Accept和Response中的Content-Type:application/json

总结：优秀的RESTful接口设计，能够根据请求的路径及请求方法就能看出这个接口主要是对具体某个资源进行什么方法的操作以及返回数据的规则等等。

但是不是所有的东西都是“资源”，尤其是在业务系统中
缺点如下：

1、有个接口是更新订单状态，你是用上面的GET POST PUT DELETE 哪个呢，看样子应该是PUT，但是路径呢PUT /tickets/12 我有时候多个接口，更新订单收款状态，更新订单支款状态，更新订单结算状态；
Restful 的路径明显不友好不够用；

2、再比如，批量删除，DELETE还好用么，DELETE /tickets/12 #删除ticekt 12 这种形式如果要传数组怎么办，url是不是不够友好？

3、再比如，Resuful要求 GET /tickets # 获取ticket列表。我们曾经有个需求，对方会把不超过1000个订单id传给我们，我们系统过滤其中一部分特殊订单；这也是个查询服务，用GET /tickets # 获取ticket列表的形式，1000个订单id显然是超过GET url长度的，这里也不合适；再者，我想开发多个条件查询列表服务，路径这么浅显然不合适；