我觉得你说的还不够。

程序员不仅不应该和一门语言绑定在一起，也不能和某个公司绑定在一起(比如大公司)，还不能和某项业务绑定在一起(比如电商、直播)，甚至不能和技术绑定在一起(要产品、销售、运营全都行)。要和时代的运势绑定在一起，和宇宙大道绑定在一次？我还是俗了，应该超脱无界，不和任何事物绑定在一起。

有追求是好的，把自己逼死就没意思了，一辈子才能吃几顿饭，开心快乐不重要么？

我理解强依赖的调用关系，肯定是要走 RPC，并且明确获得返回结果的情况下才能继续的。
那些弱依赖的，类似只是通知一下其他服务做动作的，可以做成队列异步执行的，确保最终一致就行。
但是这个界限还是比较模糊的，理论上是可以把所有对外的调用都做成队列消息，异步让其他服务处理，不过这样的话设计起来就会复杂很多，你得定义多少消息类型，异步任务啊。

如果你这个后端的 API 不仅仅是给前端提供服务的，还可以给第三方提供服务，通过他们的后端程序来进行调用。
这时针对 PUT, POST 的重复性校验就是个累赘，因为免不齐就有一些接口是要批量被调用去更新的，POST 接口本身就不是幂等的，你这么一做，硬是搞成几秒钟之内的重复调用被后端给拦截掉了。
到时候你还得写个白名单，某些接口可以允许不拦截。

我觉得这个表单重复提交的问题还应该放在更大的尺度上去看，而不仅仅是前端和后端的交互上面。

@broadliyn 我们可以针对你发明的接口规范来和 RESTful 建议进行一些有意义的讨论，来评判到底谁的设计规范更好用，更规范。

@broadliyn 在你发出自己发明的接口规范之前，我不会对你的回复进行任何无意义的评论。

@broadliyn 这里确实没有 RESTful 的规范标准，所以我也是说 RESTful 风格或者建议。RESTful 只是建议大家把 HTTP 标准更好的用起来。

每个公司确实会根据自己的偏好选择某些来实现，规避某些实现，这也是现实存在的，但是你只拿人家做的不好的来说，这就有点偏颇了。

对于 RESTful 的基本共识大家还是有的，各种开发框架也把这些共识固化下来给大家用了，可以参考 SpringMVC。

只要是有利于接口表达、使用者方便的好技术、好建议我都支持。

请看清楚本贴的题目，人家问的是 RESTful API，你可以随便写 http 接口，但请不要说自己是 RESTful。

另外既然你知道 RESTful 别家公司用的那么烂，有勇气晒一下自己发明的接口规范么？

看看你不用 Accept 头是怎么做 Content Negotiation 的，不用 Accept-Language 是怎么做多语言国际化的。

@broadliyn 首先感谢你写这么多。

本来这种帖子都是懒得回复的，看懂 HTTP 协议，RESTful 建议和国外各种 api 设计的人，不会问出这种傻问题的。

但是好奇心让我看完了所有的回复，截止发送此回复时，共有 29 个回复支持使用 404，39 个回复支持用 200。

看来还是 200 党获胜啊。

这些 200 党，请问你们仔细研究过 HTTP 协议，看懂理解 RESTful 的思想，读过 Github 的 API 接口么？

都 9012 年了，还有那么多抱残守缺、不思改变的人，也真是 shame 啊。

从最开始写 API，就知道用 200，用 get post，写了这么多年不想想有没有更好的方式么？

这还只是个 200 和 404 的争论，恐怕 200 党肯定也不允许 URL 里面出现 id 参数，不允许使用 put patch delete 吧？

支持！

一起加油吧！

什么需求！！！不好好做垃圾内容过滤，弄个这需求！！
直接给文章加审核状态，默认发布未审核，通过自动或者人工过滤之后再展示不行吗？

要是沿着你的思路走，之后分页怎么办？

@okampfer 对的，不支持多个这个特烦人，每次都得切换，不然就得开多个链接。

用 https://mozilla.github.io/server-side-tls/ssl-config-generator/ 生成配置
用 https://www.ssllabs.com/index.html 浏览器测试覆盖率
TLS1.0 TLS1.1 TLS1.2 开着就行， SSL 都关掉。

https://github.com/Sin30/Dockerfiles 最近在研究 docker ，搞了一套 Nginx + PHP-FPM + Redis + MySQL ，可以看看。挺方便的。

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/
请参考