关于 RESTful 不足的思考

在 Amazon 的时候，公司内有大量的组来维护不计其数的 service，而 service 之间的通用通讯方式是公司内部的一个框架，协议是自定的，客户端也是内部的；现在到了 Oracle，我看到这个变成了 RESTful，也就是说，协议本身变成了最常见和适用的一种。我看到有太多论述 RESTful 优点的文章了，而实际工作中也确实有所体会，比如接口和报文的可读性好，不需要特制的客户端，上手和调试都比较容易等等。但是，如果看到某个东西被冠以过多正面的评价，就要当心了。我也慢慢地体会到了一些问题。不过，在谈谈我的思考之前，我想先明确一下我对 REST 的认识，而这点，鉴于历史原因，也是我不太愿意花时间争辩的内容。我认为 REST 是一种设计和架构的方式，体现了系统响应请求交互的风格，而非接口规约，更不是什么报文协议。

对于 RESTful 的四种 HTTP/HTTPS 的方法，我看到不同的工程师有着不同的理解，而这点，是缺少足够明确的约束的。

• 第一个例子，GET、POST、PUT、DELETE 分别表示对资源的获取、创建、修改和删除。但是实际操作中，我看到一些不一致的东西。比如修改，我见过有使用 PUT 的，使用 POST 的，也有使用 PATCH 的，很难讲孰对孰错，欠缺的是规约。
• 第二个例子，使用 GET 来做查询，清晰简便，但是也有着自己的局限性，其中一个就是参数的携带。明文参数的方法并不适合传递吧比较多的参数，而且如果参数值不是普通字符串或者数值，而是数组等集合，它缺少清晰而友好的传递方式。于是我看到有一些工程师会使用 POST 来解决这样的问题，这无疑从某种程度上破坏了 RESTful 的一些规约。
• 第三个例子——版本的指定：我以前所了解到的，版本是可以再请求头部的 Accept 头中指定的，但是我看到了一些把版本号放到 URL 中的解决方案。考虑到 REST 本来也只是一种方式和风格，不能说这样的做法就是错误的，但我觉得还是缺少一个在 REST 之上更为细致的协议或者规约。
• 第四个例子，参数的指定方式，放到问号前面的 URI 里面去还是放到问号后面的参数键值对里面去，我看到了不一致的处理方式。
• ……

对于资源名称的定义，也就是 RESTful 的核心，也不适用于许多问题的解决。我用过 SOAP，也用过一些其他的 XML 协议，REST 是更加简洁的一个。如果是针对简单实体的增删改查，RESTful 无疑是有效的。换言之，它擅长通用性问题的解决，但是孱弱于特应性问题的处理。但是如果是一个复杂业务的封装，RESTful 显得力不从心。这样的封装，之所以不任其发展为通用接口，就是考虑到某些业务的特殊性，而通用接口对于特定场景的优化是不足的。就像一个简单的二维表，一个简单的 select-from 语句可能就可以解决，但是当业务复杂到多数请求都需要 join、filter、map，这就似乎很难用擅长通用性的 REST 来解决问题了，否则就要创造一大堆不易理解的、不易重用的名词在作为 resource 了。

前面提到过缺少 REST 之上更为细致的协议或者规约，这个可以进一步展开说。对于某些基于请求和响应的通用操作，和内部框架+协议的方式比较起来，不太容易统一。比如说鉴权，比如说流控，比如说性能监控，这些东西都是很常用的，但是我看到使用一个专有的内部框架会更方便地嵌入和推广这样的组件，而 RESTful 的结果就是各个项目组五花八门，对于具体字段的理解也是分歧不少。

最后一个，我想到的是客户端的生成，以前用到的内部框架，可以方便地生成客户端，而客户端的功能也比较强大。但是 RESTful 了以后，以往的一些客户端丰富的特性都要重头自己实现过，比如说复杂的参数校验，比如一些自动装包解包到业务对象的代码生成等等。事实上，这些工作是不可能省略掉的，没法借助框架完成，就要自己想办法做。我记得以往获知一个 service，为了使用客户端，想了解一下 schema，很容易就可以得到自动生成的文档，但是现在则完全不能。

基于这些种种的原因，如果从头来过，依然使用 RESTful 风格的 service，为了保持各个 service 之间的一致性，兴许一个统一的 API 框架是值得的。我理解速度在如今软件企业中的地位，但是我们总得在和可维护性的博弈中取得一个平衡。

确实软件开发没有银弹，而我自认为对于 RESTful 不足的思考还是不够深刻，如果你有很好的认识，不妨告诉我。：）

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》