写这篇文章的原因主要还是因为V2EX上的这个贴子，这个贴子中说——
“对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全，之前习惯使用 restful api ，如果说 https 只有 post 请求是安全的话？那为啥还需要 get 、put 、delete ？我该如何反驳他。”
然后该贴中大量的回复大概有这么几种论调，1）POST挺好的，就应该这么干，沟通少，2）一把梭，早点干完早点回家，3）吵赢了又怎么样？工作而已，优雅不能当饭吃。虽然评论没有一边倒，但是也有大量的人支持。然后，我在Twitter上嘲讽了一下，用POST干一切就像看到了来你家装修工人说，“老子干活就是用钉子钉一切，什么螺丝、螺栓、卡扣、插销……通通不用，钉枪一把梭，方便，快捷，安全，干完早回家……不过，还是有一些网友觉得用POST挺好的，而且可以节约时间。所以，正好，我在《我做系统架构的原则》中的“原则五”中反对API返回码无论对错全是200的返回那，我专门写下这一篇文章，以正视听。
这篇文章主要分成下面这几个部分：
目录
编程世界通常来说有两种逻辑：“业务逻辑” 和 “控制逻辑”。
网络协议也是一样的，一般来说，几乎所有的主流网络协议都有两个部分，一个是协议头，一个是协议体。协议头中是协议自己要用的数据，协议体才是用户的数据。所以，协议头主要是用于协议的控制逻辑，而协议体则是业务逻辑。
HTTP的动词（或是Method）是在协议头中，所以，其主要用于控制逻辑。
下面是HTTP的动词规范，一般来说，REST API 需要开发人员严格遵循下面的标准规范（参看RFC7231 章节4.2.2 – Idempotent Methods）
方法
描述
幂等
GET
用于查询操作，对应于数据库的 select
操作
✔︎
PUT
用于所有的信息更新，对应于数据库的 update
操作
✔︎︎
DELETE
用于更新操作，对应于数据库的 delete
操作
✔︎︎
POST
用于新增操作，对应于数据库的 insert
操作
✘
HEAD
用于返回一个资源对象的“元数据”，或是用于探测API是否健康
✔︎
PATCH
用于局部信息的更新，对应于数据库的 update
操作
✘
OPTIONS
获取API的相关的信息。
✔︎
其中，PUT
和 PACTH
都是更新业务资源信息，如果资源对象不存在则可以新建一个，但他们两者的区别是，PUT
用于更新一个业务对象的所有完整信息，就像是我们通过表单提交所有的数据，而 PACTH
则对更为API化的数据更新操作，只需要更需要更新的字段（参看 RFC 5789 ）。
当然，现实世界中，可能并不一定严格地按照数据库操作的CRUD来理解API，比如，你有一个登录的API /login
你觉得这个API应该是 GET
，POST
，PUT
还是 PATCH
?登录的时候用户需要输入用户名和密码，然后跟数据库里的对比（select操作）后反回一个登录的session token，然后这个token作为用户登录的状态令牌。如果按上面表格来说，应该是 select 操作进行 GET
，但是从语义上来说，登录并不是查询信息，应该是用户状态的更新或是新增操作（新增session），所以还是应该使用 POST
，而 /logout
你可以使用 DELETE
。这里相说明一下，不要机械地通过数据库的CRUD来对应这些动词，很多时候，还是要分析一下业务语义。
**另外，我们注意到，在这个表格的最后一列中加入了“是否幂等”的，API的幂等对于控制逻辑来说是一件很重要的事。**所谓幂等，就是该API执行多次和执行一次的结果是完全一样的，没有副作用。
幂等这个特性对于远程调用是一件非常关键的事，就是说，远程调用有很多时候会因为网络原因导致调用timeout，对于timeout的请求，我们是无法知道服务端是否已经是收到请求并执行了，此时，我们不能贸然重试请求，对于不是幂等的调用来说，这会是灾难性的。比如像转帐这样的业务逻辑，转一次和转多次结果是不一样的，如果重新的话有可能就会多转了一次。所以，这个时候，如果你的API遵从了HTTP动词的规范，那么你写起程序来就可以明白在哪些动词下可以重试，而在哪些动词下不能重试。如果你把所有的API都用POST来表达的话，就完全失控了。
除了幂等这样的控制逻辑之外，你可能还会有如下的这些控制逻辑的需求：
也许，你会说，我的业务太简单了，没有必要搞这么复杂。OK，没有问题，但是我觉得你最差的情况下，也是需要做到“读写分离”的，就是说，至少要有两个动词，GET
表示是读操作，POST
表示是写操作。
一般来说，对于查询类的API，主要就是要完成四种操作：排序，过滤，搜索，分页。下面是一些相关的规范。参考于两个我觉得写的最好的Restful API的规范文档，Microsoft REST API Guidelines，Paypal API Design Guidelines。
排序。对于结果集的排序，使用 sort
关键字，以及 {field_name}|{asc|desc},{field_name}|{asc|desc}
的相关语法。比如，某API需要返回公司的列表，并按照某些字段排序，如：GET /admin/companies?sort=rank|asc
或是 GET /admin/companies?sort=rank|asc,zip_code|desc
过滤。对于结果集的过滤，使用 filter
关键字，以及 {field_name} op{value}
的语法。比如： GET /companies?category=banking&location=china
。但是，有些时候，我们需要更为灵活的表达式，我们就需要在URL上构造我们的表达式。这里需要定义六个比较操作：=
，<
，>
，<=
，>=
，以及三个逻辑操作：and
，or
，not
。（表达式中的一些特殊字符需要做一定的转义，比如：>=
转成 ge
）于是，我们就会有如下的查询表达式：GET /products?$filter=name eq 'Milk' and price lt 2.55
查找所有的价柗小于2.55的牛奶。
搜索。对于相关的搜索，使用 search
关键字，以及关键词。如：GET /books/search?description=algorithm
或是直接就是全文搜索 GET /books/search?key=algorithm
。
分页。对于结果集进行分页处理，分页必需是一个默认行为，这样不会产生大量的返回数据。
注意：这里需要注意一下，在理论上来说GET
是可以带 body 的，但是很多程序的类库或是中间件并不支持 GET 带 body，导致你只能用 POST 来传递参数。这里的原则是：
对于简单的查询，很多参数都设计在 restful API 的路径上了，而 filter/sort/pagination 也不会带来很多的复杂，所以应该使用 GET
对于复杂的查询来说，可能会有很复杂的查询参数，比如：ElasticSearch 上的 index/_search
里的 DSL，你也应该尽可能的使用 GET
，而不是POST
除非客观条件上不支持GET
。ElasticSearch 的官方文档里也是这么说的。
The authors of Elasticsearch prefer using GET for a search request because they feel that it describes the action—retrieving information—better than the POST verb. （我们推荐使用 GET而不是 POST，因为语义更清楚）However, because GET with a request body is not universally supported, the search API also accepts POST requests （除非你的类库或是服务器不支持 GET带参数 ，你再用POST，我们两个都支持）
陈皓注：但是在 ElasticSearch 7.11 后，GET 也不支持 body 了。这是 ElasticSearch 的设计和实现不对应了。
另外，对于一些更为复杂的操作，建议通过分别调用多个API的方式来完成，虽然这样会增加网络请求的次数，但是这样的可以让后端程序和数据耦合度更小，更容易成为微服务的架构。
最后，如果你想在Rest中使用像GraphQL那样的查询语言，你可以考虑一下类似 OData 的解决方案。OData 是 Open Data Protocol 的缩写，最初由 Microsoft 于 2007 年开发。它是一种开放协议，使您能够以简单和标准的方式创建和使用可查询和可互操作的 RESTful API。
下面是对几个问题的直接回应，如果大家需要我回应更多的问题，可以在后面留言，我会把问题和我的回应添加到下面。
Restful API算是一个HTTP的规范和标准了，你要说是最佳实践也好，总之，它是一个全世界对HTTP API的一个共识。在这个共识上，你可以无成本地享受很多的技术红利，比如：CDN，API网关，服务治理，监控……等等。这些都是可以让你大幅度降低研发成本，避免踩坑的原因。
因为API是一种契约，一旦被使用上，就很难再变更了，就算你发行新的版本的API，你还要驱动各种调用方升级他们的调用方式。所以，接口设计就像数据库模式设计一下，一旦设计好了，未来再变更就比较难了。所以，还是要好好设计。正如前面我给的几个文档——Microsoft REST API Guidelines，Paypal API Design Guidelines 或是 Google API Design Guide 都是让你好好设计API的不错的 Guidelines.
不会。
很多同学以为 GET
的请求数据在URL中，而 POST
的则不是，所以以为 POST
更安全。不是这样的，整个请求的HTTP URL PATH会全部封装在HTTP的协议头中。只要是HTTPS，就是安全的。当然，有些网关如nginx会把URL打到日志中，或是会放在浏览器的历史记录中，所以有人会说 GET
请求不安全，但是，POST
也没有好到哪里去，在 CSRF 这个最常见的安全问题上，则完全就是针对 POST
的。 安全是一件很复杂的事，无论你用哪方法或动词都会不能代表你会更安全。
另外，
总之，你要明白，GET
和 POST
的安全问题都一样的，不要有谁比谁更安全，然后你就可以掉以轻心的这样的想法，安全都是要很严肃对待的。
不但不会，反而更糟糕。
说这种话的人，我感觉是不会思考问题。
不要以为你回家早就没事了，如果你的代码有这样那样的问题，别人看懂，或是出误用了你的代码出了问题，那么，你早回家有什么意义呢？你一样要被打扰，甚至被叫到公司来处理问题。所以，你应该做的是为了“长期的早回家”，而不是“短期的早回家”，要像长期的早回家，通常来说是这样的：
回应两点：
其一，遵循个规范而已，把“正常”叫“优雅”，可见标准有多低。这么低的标准也只能“为了吃饭而生存了”。
其二，作为一个“职业程序员”，要学会热爱和尊重自己的职业，热爱自己职业最重要的就是不要让外行人看扁这个职业，自己都不尊重这个职业，你让别人怎么尊重？尊重自己的职业，不仅仅只是能够获得让人羡慕的报酬，而更是要让自己的这个职业的更有含金量。
希望大家都能尊重自己从事的这个职业，成为真正的职业化的程序员，而不是一个码农！
你的工作给你权力，而只有你的行为才会给你尊重
（全文完）
（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）
(262 人打了分，平均分： 4.59 )
Loading...
