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 的路径明显不友好不够用；
比如，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¶m2=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理解不够，觉得这种变种的服务路径才是最优解，有大侠欢迎教育 :)
