Restful的理解,Restful 优缺点

时间:2024-01-29 09:49:36
写一下我对restful的理解,最近换工作面试的时候有问到我restful api的东西,工作中以前很多项目也是webapi + js前台控件的形式构建系统。实际上感觉restful太“理想化”,用起来不是特别顺手, 举例说明下:
 
先看看什么叫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
实际上呢,不是所有的东西都是“资源”,尤其是在业务系统中,缺点如下:
 
有个接口是更新订单状态,你是用上面的GET POST PUT DELETE 哪个呢,看样子应该是PUT,但是路径呢PUT /tickets/12
我有时候多个接口 ,更新订单收款状态,更新订单支款状态,更新订单结算状态;
Restful 的路径明显不友好不够用;
 
比如,Resuful要求 GET /tickets # 获取ticket列表 。我们曾经有个需求,对方会把不超过1000个订单id传给我们,我们系统过滤其中一部分特殊订单;这也是个查询服务,用GET /tickets # 获取ticket列表的形式,1000个订单id显然是超过GET url长度的,这里也不合适;再者,我想开发多个条件查询列表服务,路径这么浅显然不合适;
 
实际业务中,我们webapi的路径是这样的:systemAlias/controller/action
总结下规则:
简单查询尽量用GET,好处是可以直接带查询参数copy api路径
复杂查询和更新用POST,用的最多
不用PUT和DELETE,原因是增加复杂度,并没有带来什么好处
看看BAT的很多openapi,也是写着restful,实际没有严格遵守,都是get和post,这是也很多人不知道put和delete的原因
 
如:
//根据订单id获取订单
GET oms/order/queryOrderById?id=value1&param2=value2
 
//根据订单id List获取订单
POST oms/order/queryOrderByIdList
 
//根据条件查询订单,带分页参数
POST oms/order/queryOrderByCondition
 
//更新订单收款状态
POST oms/order/updateOrderCollectionStatus
 
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
 
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
 
//批量删除订单,带操作来源
POST oms/order/deleteOrderInBatch
 
可能是我对Restful理解不够,觉得这种变种的服务路径才是最优解,有大侠欢迎教育 :)