同事说:后台接口不能使用除 post/get 之外的方法,path 里不能带参数

[unco020511]

我写了接口文档,尽量按照 RESTful 风格写的,然后前端+部分后台同事说不能用 put 和 delete,还有 path 里不能带参数; 我问为啥,他说这样不规范 我该如何说服同事?

获取对应学期下评语:[get] /back/remark/{termId} 删除数据:[delete] /back/record/{recordId}

[unco020511]

@index90 回复你 141/146 层-你这个人说话是真的有点难听,自己仔细读读我的帖子,我哪个字嘲笑同事了?还有哪句话有你表达的那种意思?另外人贵有自知之明,这句话送给你比较合适

[registernet]

阿里的 mtop 了解一下，就是一个 url 搞定所有的代表

[index90]

@hantsy
如果只用 GET 和 POST 就已经能表达清楚，为什么一定要用 PUT 和 DELETE 呢？
“是能用 PUT，DELETE 表达的地方为什么不用呢？”，就那么想找个地方，把 REST 圣经实行下去么？

既然你认可，规范是用来降低沟通成本的。那么请看最近半年，每个月都跑出来一个“如何定义 RESTful”接口的月经贴，每次都没有结论，你觉得这本圣经还能降低沟通成本么？

Proto 定义接口： https://github.com/googleapis/googleapis/tree/master/google/api

[unco020511]

@index90 我翻了一下你的发言,发现你好像十分热衷讨论这类问题,并且很多发言都带一点怪里怪气的异味,我不认为这是良好的沟通方式

[hantsy]

@index90 Proto 好像对你很新鲜一样，但没看到我想要的东西。IDL 这种类似东西，如果没记错，很早前就有人做了，我第一眼就不喜欢，好像也一直不流行。

你要拿 REST 和 GraphQL 来讨论，我还想另眼想看。

我喜欢讨论技术，不喜欢没头脑的喷子。

我们不讨论了，不送。

[horkooo]

我觉得挺好的，我自己写的后端只允许 post，其他全禁止了

[flyico]

RESTFUL 是法律吗？一定要遵守？毛病惯的。。。
只要保持一致性，我们爱用啥用啥

[xsen]

@hantsy #159
１． delete/put 很多时候理解起来是比较让人费解
因为 delete/put 可以实现的，get/post 都可以实现——那为什么还要另外搞一套
这也是为什么实际应用中 delete/put 用的是越来越少

２． Proto 并不只是你说的在传输格方式上做文章
Proto 其实要做的就是将数据序列化这部分工作省下来，特别是内部多端(grpc 就是非常典型的应用）或提供 sdk 的方式

３．关于对外提供 API
实际应用中主流的，应该是一种简化的 REST 风格的。其实做法就如本文标题所描的，就是只用 get/post，url 不传递参数。这样使用的确实是越来越多

４．对于 url 不传递参数——这样场景是越来越多
因为很多时候有各种需求，比如，
ａ）换传输层
http 换成 ws/wss，或者 mqtt 等类似

ｂ）协议对接
简单点就是各种针对性的 bridge （比如协议、ｄｂ或第三方等等）

[index90]

@hantsy 既然讨论技术，就说说你的解决方案？扣帽子的速度还是挺快的。

我不反对 RESTful，毕竟我也有在公司内部推行 RESTful，我只是反对迷信 RESTful，以为有了 RESTful，前景就是光明的，或者说只有 RESTful 才能解决问题。追求规范，却忘了为什么需要规范。

#159 我所说的问题，能请教一下你么？怎么才叫好呢？毕竟这个也是我在推行 RESTful 所遇到的无零两可的问题。

即使有公司所有接口用 POST，但只要他的文档写得好，容易检索，我就说它是好的 API。

我从来不轻易说某样技术 low，或者某样技术烂，我列举 Proto，是因为 Proto 里面只留下方法名和 Message，和其他 AML 不同，不需要再去纠结 http method 和 url。

你说你看不到你想要的，只不过是我们讨论的不是一个维度上而已。

[hantsy]

@xsen
1. 很多时候我们很多人只用 Get/Post 是基于传统的 MVC Pages 观念，因为基本都是 GET、POST，一般根本想不到用 PUT，DELETE 的场景。在 Spring MVC，传统的 Web 程序，让 URI 看起来更合理，Spring 中 HTTP Method 可以 Override 的，所以 URI 一样可以看起来和 REST 差不多，看起来比较自然。另外对一个实际应用中，GET 操作应该最频繁的，DELETE 操作本来就少，以前有一个项目 UPdate 操作都是 Patch Method 实现，用 JSON Patch 格式，颗粒度很细。Spring 以前有一个项目 Spring Sync 专门处理 JSON Patch。JSON Patch 现在也是国际标准，Java EE 标准 Jaxrs 已经支持了。还是那么句话，该用的地方肯定用，对于类似 DELETE /posts/1 的场景，肯定比用 POST /posts/deletePost/1 要合理的得。

2.Protobuf 出来不久，Spring 就有支持了，它仅仅是除了 JSON，XML 的一个种 HTTP Message 的 Codec/Decode 方式，或者其它的什么协议。Proto 格式只是一种中间语言（应该可以归为 IDL 类型吧？）还需要生成相关的语言代码，这个我只试用过一次，这和以前用 WSDL 生成客户端代码一样，对开发人员成本是高了吗？为什么不用简单的基于 HTTP 的 REST 呢？再扯远一点，从 API 设计上 Proto 也不能简化设计过程，Proto 格式本身可以当作一种建模语言，如果像上面某位那位连 URI 怎么设计合理都不能决定，怎么可能写好一些 Proto 协议？

3，4.不传参数比较多一种情况就是使用 GraphQL，其它我想不到为什么该用参数的地方不用参数。它弥补一些 REST 缺陷，带来一些设计层面新问题。曾经我想在项目中使用，开始一段时间后发现有些问题以前没有想到，特别安全设计（ REST 可以做到很细），不久放弃了。和 Proto 相通的，也存在一种建模格式。
a ）同一 URI 换协议，太戏剧性，我想不到这情况。以前的项目嘛，都是 HTTP/REST 为主，WS，SSE 只是作为补充，解决一些实时要求。完全切换到 WS 就不考虑参数之类，也说不通吧。Google Firebase API 几乎都是 WS 协议的，但也遵循 REST 风格一些设计约定。
b ）如果你的 API 对外，有足够的第三方的人群在用，或者正要使用，应该提供 Client 语言（比如 Java，Ruby，Python，JS 等）的 SDK 才是正道，完全屏蔽掉 API 调用部分。

[ma836323493]

刚出来我也严格按照 restful 要求，后来发现有点坑前端，就一律 post 吧

[nvkou]

大家都是用轮子的人。有现成框架做好 restful 的，就对接下数据库，中间加点业务就完事了。明明是个团队原型问题，怎么就说成原则问题了。接口就是约定，时间就是金钱。恰好对方知道你的原型，也有对应轮子，不就好了。

[qbmiller]

@Leonard #8 刚写了一个 还就是用 post 了…🤣

[swulling]

风格在公司内部统一就行，ls 有说阿里的，以阿里云为例：

1. 阿里云部分产品的 HTTP API 风格叫做 RPC 风格，也就是 Action （或者说是 Method ） + Param 的方式，承载同时支持 GET 和 POST。例如 ECS API： https://help.aliyun.com/document_detail/25489.html

这个并不是阿里的同学非常讨厌 Restful 风格，这个有两个原因：
A. 业界先驱 AWS 的 EC2 API 就是这个风格，大家都知道云这个东西产品最好做了，直接 cp 就行。API 兼容很多别人的工具都可以复用。
B. 这个 API 到了网关后其实直接转成了 RPC 请求打到后端，后端根本就不用实现 HTTP API 接口，一套 RPC 打天下，开发效率高不用维护 HTTP API。

2. 但是阿里云还有很多产品，比如对象存储要兼容 S3 的 API，容器服务要兼容 K8s 的 API，为了保证兼容性，不得不使用 Restful 风格。


说几点我的想法：
1. 技术债和包袱比较重的公司，可以保持原来的 API 风格，这点无可厚非。
2. Restful 风格的 HTTP API 目前确实是业界主流，没必要在这点上去强拉硬扯。EC2 API 当年不用 Restful 还是因为当时时间太早，Restful 风格根本就不流行，到现在 AWS 也没办法换 API 了，但是像 Google 的 GCE，就都是 Restful 风格。
3. Restful API 目前生态已经非常完善，不存在哪点比不上纯 POST，仅仅是风格之争，就别扯别的了。

[0x000007b]

@binux 大哥，大家都是为了钱去工作的，给的钱少了，当然没人愿意给你干了，35 的不一定不会，35 的可能是觉得你给的钱不够

[xhinliang]

RESTful 不是圣经，RESTful 描绘的事情都太简单了（假装这个世界只有 CURD ），感觉不适合复杂的业务。

[NoahVI]

@est 为啥啊。

[Aresxue]

因为你们的业务大概率不适合 Restful，标准的 Restful 自然要通过请求方式标识资源操作类型，但实际项目中的复合业务可能包含增删改查的多个属性，从语义上就不好界定，不如把这部分简化掉，而且 http 码本身的粒度不够，大概率还是要自定义响应码和响应描述，和 Restful 也不是很搭

[ragnaroks]

打一架，谁拳头硬听谁的

[ragnaroks]

回复完才发现是一年前的，我怎么从首页点进来了...