Image

昨天的轉貼文聊到 HTTP Status Code，正好今天想起了一篇之前挺喜歡的文章，貼上來給大家
一把梭：REST API 全用 POST - 酷壳 CoolShell

分享幾個我比較有共鳴的部份，最強烈的是關於標準的部份：

Restful API 算是一个 HTTP 的规范和标准了，你要说是最佳实践也好，总之，它是一个全世界对 HTTP API 的一个共识。

在这个共识上，你可以无成本地享受很多的技术红利，比如：CDN，API 网关，服务治理，监控……等等。

这些都是可以让你大幅度降低研发成本，避免踩坑的原因。

這和作者的另一篇文章想表達的一樣，這邊作為延伸閱讀貼上來： 我做系统架构的一些原则 - 酷壳 CoolShell

只有服从了标准，你的架构才能够有更好的扩展性。

比如：我经常性的见到很多公司的系统既没有服从业界标准，也没有形成自己公司的标准，感觉就像一群乌合之众一样。

最典型的例子就是 HTTP 调用的状态返回码。业内给你的标准是 200 表示成功，3xx 跳转，4xx 表示调用端出错，5xx 表示服务端出错

我实在是不明白为什么无论成功和失败大家都喜欢返回 200，然后在 body 里指出是否 error（前两年我在微信公众号里看到一个有一定名气的互联网老兵推荐使用无论正确还是出错都返回 200 的做法，我在后台再三确认后，我发现这样的架构师真是害人不浅）。

这样做最大的问题是——监控系统将在一种低效的状态下工作。监控系统需要把所有的网络请求包打开后才知道是否是错误，而且完全不知道是调用端出错还是服务端出错，于是一些像重试或熔断这样的控制系统完全不知道怎么搞（如果是 4xx 错，那么重试或熔断是没有意义的，只有 5xx 才有意义）。

有时候，我会有种越活越退步的感觉，错误码设计这种最基本最基础的东西为什么会没有？并且一个公司会任由着大家乱来？这些基础技能怎么就这样丢掉了？

當我們遵守某些標準的時候，也就代表有了這套標準底下的許多工具和服務可以使用。如此一來就能夠提高我們的效率

除了上面這項，前天（2/4）分享的文章中有提到冪等性，而當我們遵循規範的時候，API 的冪等性其實可以從 HTTP 動詞中區分出來：

API的幂等对于控制逻辑来说是一件很重要的事。所谓幂等，就是该API执行多次和执行一次的结果是完全一样的，没有副作用。

  • POST 用于新增加数据，比如，新增一个交易订单，这肯定不能是幂等的
  • DELETE 用于删除数据，一个数据删除多次和删除一次的结果是一样的，所以，是幂等的
  • PUT 用于全部数更新，所以，是幂等的。
  • PATCH用于局部更新，比如，更新某个字段 cnt = cnt+1，明显不可能是幂等操作。

幂等这个特性对于远程调用是一件非常关键的事，就是说，远程调用有很多时候会因为网络原因导致调用 timeout，对于 timeout 的请求，我们是无法知道服务端是否已经是收到请求并执行了

此时，我们不能贸然重试请求，对于不是幂等的调用来说，这会是灾难性的。比如像转帐这样的业务逻辑，转一次和转多次结果是不一样的，如果重新的话有可能就会多转了一次。

所以，这个时候，如果你的API遵从了HTTP动词的规范，那么你写起程序来就可以明白在哪些动词下可以重试，而在哪些动词下不能重试。

這篇文章中還針對 POST 黨(?) 一些常見的論述進行反擊，例如 POST 更安全、全用 POST 可以減少溝通、可以早點下班回家等等

相當值得收藏，並且在同事想要一把梭的時候先把這篇甩在他臉上

Image

那麼，今天的轉貼就先到這邊。明天見 ><

不知道是不是太想休假，明明再撐一天就好卻開始咳嗽了囧