Restful的理解，Restful 优缺点

写一下我对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 的路径明显不友好不够用；

 

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

 

再比如，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理解不够，觉得这种变种的服务路径才是最优解，有大侠欢迎教育 :)