REST应该进垃圾桶

API

note：

摘要：

作者： Pakal De Bonchamp

正文：

几年前我为一个大型通信公司开发了一套系统，需要在各种web服务间通信，从老掉牙的系统或者商业伙伴的系统中取数据。

整个事情乱成一锅粥：抽象WSDL，不兼容的库，奇妙的bug要多少有多少。所以我们尽可能用RPC通信。

我们开发的第一台服务器很简单脆弱；但是随着迭代，我终于可以支持各种语法（包括Apache自己定义的XMLRPC语法），把Python的异常转换成错误代码，处理各种错误，记录请求日志，验证输入数据等等等等等等等等。

几句话就可以连接新的API，加几行装饰器就可以支持各种输出。连接微服务也特别简单：网管就可以自己干，对软件而言这个过程是透明的。

然后REST出现了。

REST重新定义了服务间的沟通：RPC已死，未来是RESTful的。每个资源都有独立的URL，使用HTTP协议。

然后呢？天塌地陷。

REST有什么问题？

给个例子吧。以下是一个API，去掉了数据：

创建用户(用户名, email, 密码) -> 账户id
加入订阅(账户id, 订阅类型) -> 订阅id
发送验证email(账户id) -> null
取消订阅(订阅id, 理由, 立即=True) -> null
取账户信息(账户id) -> {数据}


定义一些异常后（例如，参数不对、参数缺失、工作流异常），再抛出一些重要的错误（例如，用户名已占用），整个API就好了。

API很简单易用稳定，背后的状态机很完善，用户做不出非法操作（例如，用户不能定义创建时间）。

用RPC写这个API：几个小时。

RESTful呢？

RESTful没有标准，没有定义，只有个“RESTful哲学”，每个地方都可以拎出来讨论，各种hack。

上面的功能怎么能直接映射到简单的CRUD操作？发送验证邮件是把“必须发送验证邮件”更新一下？还是创建一个“验证邮件”？在宽限期内取消订阅这个命令能不能用DELETE，过后能不能回滚？取账户信息如何写的RESTful？

资源怎么定义？是不难，但也得定义啊。

怎么用几个HTTP代码表示错误信息？

输入输出的格式是什么？怎么序列化？

HTTP动词、URL、请求、请求头和状态码的分界线在哪？

整个事情就是在重复造轮子：造的还不是好轮子。造的轮子还需要一大堆文档，而且肯定违反RESTful规则。

为什么RESTful这么难用？

我们看看REST的设计哲学。

REST的动词们

REST不是CRUD，REST用户们肯定不支持混用这两个概念。然后他们就开始研究创建的POST、取的GET、更新的PUT和PATCH，加上删除的DELETE了。

REST的意思是这几个东西就足够了。好像是的：“今天我对汽车座椅UPDATE我的身体，CREATE发动机点火，油箱自己DELETE”。仿佛多多少少看起来不怎么像人话？

就算简单化是好的，REST也没做好。为什么PUT、PATCH和DELETE在web表单上从不使用？因为这几个东西百害而无一利。读就是GET，写就算POST，这就够了。或者你不想被运营商劫持，那就只用POST呗。

如果用PUT更新资源呢？可以，但是你需要和GET取到的数据格式一样，包括一大堆只读数据（创建时间、最后更新时间，服务器上的什么token）。请问您是准备不管RESTful规则了？还是老老实实组装一个请求，PUT上去了服务器报409 Conflict，因为服务器上某个值变了？然后再GET一发，重新组装再PUT？还是你觉得服务器会忽略只读的参数？（服务器有可能忽略了，也有可能直接炸了哦）要是某些值根本就不能让你GET呢，例如，信用卡密码加有效期？RESTful根本处理不了这种只读的参数。

哦，别忘了如果有多个客户端，PUT有可能造成竞争条件哦。哪怕每个客户端要更新的参数不一样哦。

行，用PATCH。那请问您怎么用PATCH？只发需要改变的参数，希望服务器自己调节？有时候服务器不能理解输入，或者某些参数不能变（信用卡信息等）。然后您又违反了RESTful的要求：PATCH不是发一堆参数让服务器猜，而是需要给服务器一些指示。慢慢设计吧您。

DELETE呢？您不能只DELETE一部分内容，例如PDF的一页：DELETE不能有请求体。当然大家已经不管这套了，因为没人这么写。连RFC 2616都撒手不管了。

所以根本没人能写出完全RESTful的API。很多人用PUT指向URL创建资源，但是RESTful要求你对上级URL发一个POST，在Location头（和301那个不是一个意思）里面写上地址。当然了，谁管这坨烂事。

手写URL挺有意思，但是您写好了urlencode吗？等着被SSRF/CSRF上吧。

REST的错误处理

猴子都能把功能写上去：但是好的程序员会做错误处理。

HTTP有很多错误码：我们来瞧瞧。

HTTP 404表示某个资源不存在，是不是很直观？如果您没设好Nginx，您的API用户干脆把用户全删了，因为这些用户不存在啊。

HTTP 401表示用户没权限是不是很棒？然而，如果您在浏览器里这么玩，您的用户有可能看见浏览器蹦出一个框让他们输入用户名和密码。

HTTP比RESTful的历史长的多，有很多约定俗成的东西。用HTTP状态码报错就像用牛奶瓶装剧毒废物：总有一天你会药死谁。

有些HTTP状态码是WebDAV专用的，有些是微软专用的，有些不知所云。最后大家开始瞎用状态码，什么HTTP 418（查查呗）什么的。或者，所有的错误全用HTTP 400，里面套一层状态码。或者，全用200，里面写个详情，等人读。换种方法把自己药死吧。

REST的概念

REST搞了一大堆概念：我从官网摘录一些。

REST是客户端-服务器架构，客户端和服务器的关注点不同。嗯呐。

REST在组件中通用。和没说一样。

REST分层，每个组件看不到本层上面的东西。就是真正用脑袋想出的架构呗，有什么奇怪的？

REST是stateless的。嗯，有个数据库，但是不认识客户端？也不对，因为数据库保存了session和token，但是随便吧。这东西到底怎么比其他的协议高明了？

REST可以利用HTTP缓存。好吧，至少GET可以。但是本地缓存不够吗？想想一下ISP劫持，再考虑一下你的所作所为？或者某个Varnish没配置好，所以缓存没更新？这种系统就是不安全的：缓存虽好，但是把几个点用GET就得了。

REST性能高。是吗？本地的API最好功能强大，开发方便；远程的API最好粗放，减少网络压力。RESTful完蛋了，永远有N+1请求问题：要取数据，必须每个参数都发一个请求，而且不能并行化，因为请求互相依赖。简直是自找麻烦。

REST兼容性好。是吗？那为什么还搞/v2/这种URL？API的兼容性不难，只需要好好设计：REST不怎么样。

REST简单，大家都知道HTTP。我还知道鹅卵石呢，但是我照样用钢筋水泥盖房子。所以XML是文本语言，HTTP是文本协议。想写功能需要定义很多东西，然后就是重写了RPC。还不够吗？

REST简单到可以用curl一句话读取。curl可以发任何请求。GET很简单，POST火葬场。最后您不还得老老实实用Postman嘛。

客户端不需要预先知道服务器的信息。牛。我发现这个东西和HATEOAS经常一起出现。但是讲道理，客户端也是人写的啊。客户端不会瞎请求API，然后一点点猜服务器的配置；一般不都是客户端要求服务器开放某个端点嘛，否则怎么开发？

那怎么办？

别考虑是不是正确了。把活干了是真的。

真正的问题是：需要写一个类似RESTful的API，怎么写最快？

服务器怎么办？

任何框架都可以设置URL端点。利用这个吧。

Django可以自动创建这种API，就是在SQL或noSQL加一层。如果就是HTTP的CRUD，这样一般就够了。但是如果想做事情，那么什么东西都不大好用。

慢慢写逻辑吧。

客户端怎么办？

不怎么办。

老老实实看文档，看看怎么请求，怎么错误处理。

自己写URL，慢慢连接吧。多试试。

大的web服务怎么办呢？

每 个 平 台 自 己 手 撸 客 户 端。

我之前用过一个订阅系统，有PHP、Ruby、Python、.NET、iOS、Android、Java官方客户端，还有社区的Go和NodeJS客户端。

一个客户端一个Github repo。一大串commit，issue和PR。自己的用例。架构差不多是ActiveRecord和RPC代理那样。我们在写各种连接器上浪费了多少时间？

结论

过去，各种语言的工作流差不多一致：向某个东西送输入，取输出。一直没什么问题。

REST呢？鸡同鸭讲。前脚赞扬HTTP标准，后脚就开始瞎写。

微服务开始流行了：但为什么用网络把各个库连起来的事情这么难？

肯定有人开始喷我，给我丢点代码，告诉我REST可以在任意的数据上进行操作，就像当年的超链接那样。或者告诉我人丑得多读书，我没搞明白REST。

我不管这些：没有的技术就是垃圾。我几个小时能用RPC写好的东西现在几周都写不完，浑身破绽。开发不是灵机一动。

RPC可以完成99%的工作，各种旧方法虽然不完善但是能干活。在HTTP上包一层REST纯属浪费时间。

REST嘴上说简单，其实复杂；

REST嘴上说稳定，其实脆弱；

REST嘴上说互用，其实破碎。

REST就是新时代的SOAP。

结语

未来还是可以展望的：还有很多其他的协议，无论是二进制还是文本，有无schema，利用HTTP2，等等。我们不能被困在web的石器时代。

批判

本文一出立刻引发了讨论狂潮。

Phil Sturgeon称，RPC和REST并不冲突。

RPC有自己的用处，而REST也可以利用JSON-API或OData格式。在必要时，也可以使用传统的API定义方法————能做事就是好的。

Phil认为，HTTP错误代码不能代替错误处理————使用API的双方必须规范文档并逐个处理错误。RPC也是一样。

Phil说，REST API更直观，比RPC需要的文档量更少，因为有很多约定俗成。

对于更新冲突问题，Phil认为PUT不解决这个问题：服务器的状态是PUT的最后一个指示。而PATCH有自己的RFC 6902，和其他标准没有关系。

关于DELETE的内容问题，Phil指出，RFC 7231中没有对这个问题进行定义：服务器可以选择接受一个有内容的DELETE请求。

至于误用缓存问题，Phil认为这不是REST的问题，而且缓存是不可避免的。正确使用HTTP 201可以更好的表达“请求已经成功，请稍候”这个概念。

关于“滥用400错误”，Phil觉得这是约定俗成的：不存在一种办法让客户端不需要读文档就可以处理错误。

原作者认为提出C-S架构是吹嘘：Phil反驳说，RPC很多时候分不清这种问题。

提到“通用性”问题，Phil对此不同意：Phil认为，这个通用性纯粹指出使用者不应该在REST内部再搞一个RPC或GraphQL。

至于Session，Phil觉得这种技术决策是绝对错误的：一个token会方便的多，而且可以扩展。Session在单机还可以，开负载均衡就是灾难。

关于缓存问题，Phil强调，memcache这种缓存和HTTP缓存完全不同。所以需要缓存的数据必须正确设置HTTP头，方便中途缓存；如果一定不需要缓存，那么也可以强行刷新缓存。

作者认为REST有N+1请求问题；Phil说写上需要请求的具体内容即可解决。而且现在流行HTTP/2，多发请求也不会造成很大的压力。

至于curl难写，Phil说，难道现在还有人不用Postman吗？

至于客户不需要预先知道服务器信息，Phil强调，REST的目的从来不是这个。

自己手写客户端？Phil表示使用OpenAPI可以自动生成。

最后，Phil建议读者研究JSON Hyper-Schema————这个协议可以解决上文中的大部分问题。

查看英文原文：https://medium.freecodecamp.org/rest-is-the-new-soap-97ff6c09896d

https://philsturgeon.uk/api/2017/12/18/rest-confusion-explained/