sin30

我觉得你说的还不够。

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

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

我理解强依赖的调用关系，肯定是要走 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 首先感谢你写这么多。