【Rest】Restful http实现必须小心的坑

这里说的坑，都是实际项目中遇到的，记录下来，也与读者分享。

1. Content-Length一定尽量与body长度一致

Content-Length用来标识http请求or响应的body的长度（即字节数），是http报文分界的一种方法。由于程序bug或者故障，有可能导致http报文中的body长度与Content-Length不一致：

1. http请求的body长度与其Content-Length不一致
   后果

   1. Content-Length > body长度，则服务器端卡住，只能通过超时或者关闭连接解决；
   2. Content-Length < body长度，则连接腐烂，只能关闭连接（影响长连接效果）。

2. http响应的body长度与其Content-Length不一致
   后果

   1. Content-Length > body长度 客户端卡着，只能通过超时或者关闭连接解决
   2. Content-Length < body长度 连接腐烂，只能关闭连接

这么看，Content-Length应该是要一定与body长度一致，为什么说尽量？因为出故障时我们可能无能为力：比如我们数据库记录了一个文件大小为100MB，于是设置Content-Length=100MB，然后把文件内容作为body返回客户端，但是文件已经损坏（只有读的时候才能发现），只有50M，由于http的start line和headers已经发给了客户端，没法更改了，客户端收到50M内容后，继续等待接收剩下的50M，直至超时或连接关闭，表现为客户端卡着。

2. 参数parameter最小化

举例： 如果我们有2个接口（来自AWS S3文档）

设置跨域规则接口

PUT /?cors HTTP/1.1
Host: bucketname.s3.amazonaws.com

设置生命周期管理接口

PUT /?lifecycle HTTP/1.1
Host: bucketname.s3.amazonaws.com

那么服务端应该这样实现：

1. 参数只有cors -- 按照设置跨域规则来处理
2. 参数只有lifecycle -- 按照设置生命周期管理来处理
3. 否则 -- 返回400 Bad Request

不遵循的危害：影响接口扩展

比如 如果前期服务器将/?lifecycle和/?lifecycle&haha同等对待，那么由于Rest API是开放的以及客户端实现的不确定性，不好保证有的用户发的是/?lifecycle&haha接口。如果后期服务器想加个接口/?lifecycle&haha以实现其他功能，则因为该接口可能已被当做/?lifecycle来对待而造成困扰。