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

[unco020511]

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

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

[zjsxwc]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

[jowan]

@darknoll 没啥困难啊 我们就是拦截器处理的 只是前端抱怨的理由啊

[tolking]

这种还是听后端的，像我们全部用 post

[wupher]

唉，你们同事不一定愿意学习新知识或者新技能。

如果相性不合，还是早分手好。

[nooper]

doge~

[xxdd]

记得之前 V 站有个 delete 接口被 google 爬虫爬的 ··· 文章全被删了 哈哈

[szpShang]

要么适应他们，要么改变他们，要么就滚。


反过来你想，规则越少，是不是管理越好。条条道路通罗马，如果你的管理只允许两条道路才能走，是不是好控制。每个人都想自己的方式去罗马。管理是不是越复杂了。

[Vegetable]

不让用非 getpost 就算了,path 带参数也不行?任何一个后端框架的路由部分都要明确说明是怎么解析 path 参数的吧?

[lxrmido]

锅在各个占据市场又不思进取的安全厂商上吧……
每次用 POST/GET 以外的，安全扫描报告就来个“未关闭 OPTION”的中位漏洞
要不就是请求莫名其妙被拦截，让 WAF 方看日志就是“不安全的请求方式”、“疑似攻击”
愁……

[securityCoding]

@xxdd 这。。。。233

[micean]

@cryingsky

历史软件原因
缺少权限验证

[JoanVon]

其实这个不允许使用，有些还是测试的自动化安全扫描的锅...对 put delete 这种请求会报安全错误。。每次解释都费劲，最后就妥协了。只用 get post 了...

[fkdog]

楼主就一个小年轻，还有楼上扯什么不爱学习的，我可去 xxx 的吧。什么时候 api 设计风格变成了一种专业技能了？

restful 只是一种 api 设计风格，什么时候变成了强制规范了？有什么 PUT/DELETE 能完成而 POST 不能完成的东西么？
非要把 restful 当成圣经一样是不是傻？搞得自己弄个 restful 就高人一等一样。团队的约定是什么样的，那就好好去遵守行么？

后端遗留有很多历史代码，你这边自作主张加了 PUT/DELETE，可能后端需要做其他的调整，特别是 java 这种各种拦截器了，或者是运维网关上有禁了 PUT 之类方法的。

综上，2020 还 restful 至上的，有一个算一个傻 x。整个阿里巴巴 api 网关就用 post/get，撑起了整个亿级的微服务系统，你那点破流量的项目还在纠结 put 和 post，不觉得滑稽？

[mysunshinedreams]

正确吧，我记得之前在一家公司的时候，BGP 把 put 请求拦截了，所以以后一般不用了。
我司目前也不允许请求 URL 上写 pathVariable，因为流控无法对这种情况生效。

[SY413927]

恰好我是前端
恰好我们之前也遇到过
先不说 put delete 的问题
path 带参数，是真的恶心人啊

前面几十个接口全是正常的 post 带 body，
突然一个查询列表接口，要求我把参数拼在路径上
我拼个锤子哦
虽然我写起来不麻烦
但是我不舒服，就怼回去了

[holinhot]

全 post 然后用 json 包起来

[chairuosen]

这样挺好的

[exploreXin]

RESTfull， 是啥都不知道，就别想跟对方沟通了，交流成本太高，放弃吧。如果整个团队都把不规范当做规范来做，那么你的规范就是众矢之的，要么忍要么滚，简单的话语里蕴含职场大哲学，哪个神经病会承认自己有病？在一堆精神病人群中想保全自身性命的唯一方法是跟他们 “同流合污”，同时不要忘记自己写烂代码不是自己只能写烂代码，而是选择写烂代码，等羽翼丰满，钱和技术都积累够了，qtmd 规范吧，老子滚了，你们继续你们的规范吧，我去找其他适合我的团队去了。

[wc951]

@fkdog 虽然你扯了阿里的虎皮当大旗，但其实阿里的 api 也并不是完全统一的，至少阿里云的 api 文档明显可以看出不同的团队风格确实不一致，像容器服务的 api 就是 restful 的，更有 oss 这种完全和 s3 一样的，也有弹性伸缩，ecs 那种通过 action 参数区分 api 的

[iugo]

直到后端开始为钉钉小程序写服务, 才知道为什么要这么做.

部分手机上的钉钉小程序不支持 PATCH, PUT, DELETE 等常用方法.

[iugo]

@SY413927 如果不是网关撑着, 从网络角度来说, 参数放在 path 里后端做起来更快. method URL, header 这些都会在 HTTP 请求接收的时候就收到完整的, 但 body 一般会以流的形式传入, 肯定是慢与 path 的.

当然, 如果后端有统一的网关, 这些都是网关的事儿, 对后端来说都一样.

[iugo]

有些事情, 的确不是优雅, 但也是有原因的.

比如提交数据的时候用 GET. 比如某某公司的日志记录.

比如获取数据的时候用 POST. 比如参数放 path query 里 URL 超长了.

[markgor]

我也覺得使用 POST/GET 比較好。
第一：常規請求就是使用 POST/GET 進行的，這兩個方式一般不會翻車。
第二：由於 PATCH/PUT/DEL 請求比較少眾，如果為了方便和通用性，還不如改為 POST/GET。
第三：WAF 一般都會攔截這些操作(當然可以手工開啟)，另外自動化滲透也會爆“疑似配置不當”，如果是網警出函，則需要書面寫說明回復。(當時有個站點由於需要跨站操作，開啟了 OPTION，但是有配置 allow，最後還是一個月收一次函，第二次收函時候直接把 OPTION 關了，域名增加多了個解釋就好了..)..

使用 PATCH/PUT/DEL 這些
優點：在於遵守 resetfull 的建議，通過接口 method 就能大概知道做什麼的了。
缺點：上面的 1、2、3.

使用 POST/GET 這些
優點：上面的 1、2、3.
缺點：不夠 resetFull 優雅，需要從接口參數才能看出大概做什麼的。

但是，現在基本的 api 都有搭配文檔的，所以我覺得已經不需要從 method 來看出他是做什麼的，畢竟就算你能從 method 看出作用，最後還不是要乖乖地看文檔？

[DelayNoMore]

是的，我的 Django 框架全是 post 和 get

[hitsmaxft]

你只要写个 api 的封装，自己定好参数， 出了问题丢给他自己查去。。有什么关系

[binux]

我拓展说一下为什么，这就是为什么在国内「 35 岁以上不要」的原因。

从这贴可以看出，35 岁程序员的经验都是什么「这么做是有原因 」，而不是「 我在 35 岁的时候把网关拦截 OPTION 的 BUG 给改了」。就这样的和 25 岁的程序员有什么区别？
10 年的经验没有用在把系统变得更好，没有把路拓宽，而是守着一条泥巴路，然后拦着后辈说别的路走不通。这样的「 35 岁以上不要」也罢。

[liuyibao]

@fkdog 👍🏻

[IamUNICODE]

以前带了个小弟，来的时候跟他说获取数据用 get，修改删除用 post,因为如果用户被禁用还是可以获取数据，但是不能增删改，结果他偏要用别的，等我反应过来的时候都上线了，结果临时改中间件，现在想来还是头疼。

[hitsmaxft]

restful， 说实话，用的地方不多。简单场景下，patch 里带参数，前后端的都麻烦， 涉及到 path + param 的参数解析合并问题。

path 可以在协议层高效处理，不用去字符串拆分 querystring，高性能网关会希望明确通过 path 区分目标服务

按我经验聊聊吧， /path 一般是用于隔离不同的目标业务
?querystring 用来提交参数， 再复杂点，涉及写入就要求 post 和 校验 session

比如你这个 /remark /record 其实都是 data query，/query?type=remark&id=123 区别不大。

但是对于 html 路径 比如访问某个人的页面 /person/id231 显得干净一些。

[gaius]

restful 不同的接口请求路径一样，做权限还得在接口上写注解

[vow]

@fkdog 这是明白人 restful api 该用的时候可以用 如果遇到复杂逻辑该不用就不用, 没必要较劲

[bnm965321]

上面有人说阿里的网关都是 GET/POST 支撑的，不知道阿里云算不算阿里的网关: https://www.alibabacloud.com/help/zh/doc-detail/31982.htm?spm=a2c63.p38356.879954.30.1ea6356aX99mJf#reference-iqc-mqv-wdb

[alphakevin]

努力让自己变得更牛，做到架构师，那时后端就不敢怼你了接口文档了！在一个低效的团队中，话语权掌握在“资历深”的人手里。当然你到了那个位置，也不会纠结用那种 method 了

[luxinfl]

个人觉得 restful 风格挺麻烦的，这主要还是看公司吧。想快速开发的一般不会这样做吧。像我们，统一使用 post，连获取数据都不用 get

[SteveAlan]

能说说 restful 可以带来什么效益吗？一直不理解

[unco020511]

@binux 有一些体会;我认为安全不通过应该是考虑安全团队去更新基础库和组件,而不是以这个理由来说 rest 不规范,实在有些牵强,可以说当前不适合,先别用;

[unco020511]

@fkdog 楼主 java 确实是小年轻,因为原先是移动端和前端,刚接手 java 业务不久;我不认为阿里的网关都是 get/post,我接入过阿里的服务

[SimonOne]

@xxdd #106 @securityCoding #110 https://www.v2ex.com/t/336226?p=1

[unco020511]

大家的每一条评论我都有认真看,感谢大家的建议.

[RJH]

获取对应学期下评语:[get] /back/remark/{termId}
这种其实有个痛点，如果系统统一搞了方法签名的话，URL 带参等于又要额外维护一套方法签名的逻辑。
如果是对外的厂商，你提供的 sdk 也需要进行支持，无形中增加了不必要的工作量。

[index90]

哎，又是月经贴。
RESTful 本身不能算规范，更像是方法论，它告诉我们一种“说得通”的如何设计 API 的方法。并不表示它就是规范，全互联网只能按照它这一套来设计 API。
RESTful 的目的，是让 http method，url 具有了语义，简言而之，就是你看了我写的 method 和 url 上的单词，你就知道我的 API 是用来干嘛的了，不需要我额外的文档描述。这是它的最最最主要目的。
而网络传输，路由策略，网络安全等等，均不在 RESTful 所讨论的范畴里。

在你吐槽别人没有遵循 RESTful 那一套时，能不能先了解一下别人如此设计 API 的目的是什么？基于立场去讨论问题，是没有意义的，你连对方的立场都不许了解，上来就喷。

再来说规范，规范是一起共事的人达成的一种共识，价值在于降低沟通成本。如果你的团队已经有一套已经达成共识，大家已经熟知的约定时，你不应该去打破它，而是尽快掌握这套约定，成为团队的一员。如果你继续坚持你所认为的规范，让团队所有人都迁就你，那就已经失去规范本来的意义。

[unco020511]

@index90 是不是月经贴我不知道,因为我确实是第一次在 v 站发开发相关的帖子;我也没喷啊,哪个字眼开出来我喷了,反倒是你....

[lihongjie0209]

@unco020511 #136 很多情况下安全都是客户找第三方去做的, 你不可能去要求安全团队做什么

[fkdog]

@bnm965321
阿里云 OSS 这套 restful API 是完完全全照搬亚马逊而不是阿里云自己设计的。
亚马逊 S3 现在云存储服务的事实标准。各大云服务产商的云存储服务都实现 S3 api 的兼容。

[fkdog]

@binux 所以，不用 restful 就是走泥巴路哦？用 restful 就是拓宽道路走向更远的未来？
我可以研究的东西有好多好多，为什么要花时间在一种设计风格上争论个没完没了？
存粹一个设计风格取舍的问题也能扯到 35 岁。你独清？

真以为现在互联网项目是像以前传统软件开发一样一套代码可以流传个几十年呢？就现在中国互联网开发速度，一套代码能撑五年以上就已经很不错了。基本上转了 4、5 手面目全非，然后等着下一轮重构了。

而且现在架构风格都在往微服务架构方向转，在微服务架构方向下，那些代码解耦合、可扩展、维护性之类的工程方面优势也就没有那么重要。

[index90]

@unco020511 人贵有自知之明，自己看看自己发的贴，同事已经告诉你不能用 put 和 delete，并告诉你原因，这是他们的规范。而你的问题呢？
你不是问，这样做主要出于什么考虑呢？而是问，我应该如何说服我的同事？
背后潜台词不就是：我的同事竟然称之为规范，哈哈哈哈，笑死人了，这年头竟然还有不知道 RESTful 才是规范的人，v2er 各位评评理，我该如何怼回去。（当然这里我用了夸张修饰啦）

[markgor]

@binux 哈哈，又見面了，上次我記得也是在說 api 規範上面討論過。
首先我認同你所說的，我年輕時候也是這樣想，為什麼沒有人能打破陳舊？
但每次打破陳舊的背後背負的責任實在太重了，現在年近 30，雖然沒達到你說的 35，但我的思想已經接近了，以前留下來，沒有大問題，不做修改。

回到題主的問題中。
我不可能頂著壓力，跑去懟全世界，要求把 api 接口都按 resetFull 重新設計，然後說出一大堆冠冕堂皇的理由，但最終明眼人都能看出來，這小子為了“好看”，“跟風”所以要求改。
老實說，使用 PUT/PATH/DEL 來處理對應的業務，除了優雅外優點在哪裡？


對了，不是不願意學些，而是不願意在生產環境上學習。
我記得你說過你的業務基本是對接海外的產品，那麼我只能說國內環境不一樣。
就權當我能把運維前後端說服了，
大家都願意去對現有系統進行修改。
然後後端出現了一個新的問題。
此時此刻，後端心理肯定在罵我的，甚至還想甩鍋給我。
國內的環境你有時間可以看看阿里雲的前世。

[binux]

@fkdog #145 是，因为你不知道什么是好的。不管你做什么，做再多也没用。
@markgor #147 我比你大一些，这里面首先是个态度问题。知道什么是好的设计，什么是 bug，什么是 feature。
而且就 LZ 这个问题，你知道 X-HTTP-Method-Override 这样的方案吗？ API 设计还是 restful，但是可以 fallback 全都是 POST。这样是不是既满足了优雅，又符合业务了？
从小的地方，这里改一点，哪里推进一下。当真的要推一个重新设计的时候，你会发现这时就不这么难了。

[iCD]

支持 get 不错了 我们只能写 post 接口

[tianshiba]

@binux 哈哈，你的观点真好笑。

[enjoyCoding]

从 http 语义的理解上不应该使用 delete,因为现在大多数不回去删除数据,而是将更新数据库的标志位.
至于 put 用于更新是没有问题的.

[hantsy]

@sunzongzheng 你公司是手动从 Socket 分析的吗？

如果用 Spring，或者 Jaxrs 都很容易，即使是用一些纯 HTTP 客户端，如 OkHTTP，Apache HttpClient，也很简单吧。

[hantsy]

@index90 公司内部 API 设计怎么烂都不要紧， 自己人调用随便怎么搞，外人都不好说你的好或者坏，只要你老板认可就行了。

但是，如果是对外公开 API，不遵循标准或者约定（ REST 也算是一种约定吧），总说不过去，你总不能强迫别人去用你的一套吧。

[hantsy]

@binux 这种 Fallback 设计还是可以接受的，Spring 本身也是支持 Method Override 的。

[markgor]

@binux

你知道 X-HTTP-Method-Override 这样的方案吗？<---確實之前不知道。
但剛看了，需要後端配合，當收到 X-HTTP-Method-Override 時候重寫 method。
但其實就是過了安防那一塊吧，waf 等不需要進行處理，nginx 等也不需要額外配置其他。
還有就是後端一開始如果是完完全全按 resetfull 設置的話也可以不用進行修改。

但是如果我援用 POST 來跑，除了優雅，性能上有多大的區別呢？

如果是新開發的應用，用什麼大家提前說好了我覺得問題不大。
但是修改現有系統，你覺得呢？除非我是老闆，否則我單以“優雅”二字要求後端和前端去修改，可能性不大吧。


“从小的地方，这里改一点，哪里推进一下。当真的要推一个重新设计的时候，你会发现这时就不这么难了。”
這句話，我以前一直都相信。
但是往往是，“这里改一点，哪里推进一下”，最後出 BUG 了，然後修復後整條業務線平靜下來，我得到的只是罵名。
（*說句題外話，曾經試過，幫別人修改一下 HTML 靜態文件，然後過了兩天，對方 oracle 掛了，對方運維排障，前 2 天有人改過東西。嗯沒錯，這鍋最後我背了，後面排查是因為 listen log 超 2G 的原因，但也不重要了，反正鍋已經牢牢扣我身上）

[hantsy]

究竟怎样的 API 才符合真正的 REST 风格，估计一百人有一百个不同的说法。

Fielding 博士的论文被认为是 REST 的定义，后来又有了 Richardson 成熟度模型来判定 REST 规范级别（主要针对 HTTP 协议, REST 不局限于 HTTP ）。REST 约定只是提出一些 API 设计建议，让它看起来更符合 HTTP 语义，说白了，就是用 HTTP 协议最自然的方式表达出来。

GET /posts?type 全部 POSTs,支持 Type 过滤，返回 200
GET /posts/{id} 通过 ID 查询单个 POST，返回 200 或者 404
POST /posts 创建新 POST， 返回 201，Location 指向新建的资源 URI
PUT /posts/{id} 更新某个 POST， 返回 204 （或者 404 ）
DELETE /posts/{id} 删除某个 POST， 返回 204 （或者 404 ）



1. URI 表示资源或者资源的集合。
2. HTTP Method 表示行为，而不是放到 URI 中去。
3. 返回使用 HTTP Status 表示返回状态。

[不要太纠结 HTTP 规范，如果按规范 PUT 也可以新建，PATCH 用于更新操作更适合，JSON Patch 才是更新理想格式]

有人说 REST API 麻烦，我一直不解。难道用一些毫无规律的 API，加上一些狗屁不通的 API 文档就是最好的方式。有人还搬上什么大厂的什么服务了多少 XXX 来作证，也太奇葩了吧，这跟讨论 API 设计的优劣有什么关系。

[hantsy]

@enjoyCoding 这一点没错，但是

1. 设计时可以考虑的是，并不是所有资源都有 DELETE 操作。
2. 一些 DELETE 操作可能转化为 Soft Delete，即更新数据库中删除标志位。

[laravel]

一个人想怎么搞都行，团队那就要折中了，比如增加的工作量 和 增加新的东西带来的不适感，你觉得好，别人觉得一般。

[index90]

@hantsy 什么叫做烂？什么叫做好？评价标准是什么？
只用 POST/GET 就叫做烂了？用 POST/GET/PUT/DELETE 就叫做好了？
只要遵循 REST 就叫做好了？那么怎样才遵循 REST 呢？能用上 PUT 和 DELETE 就叫遵循了？
LZ 例子：“获取对应学期下评语:[get] /back/remark/{termId} 删除数据:[delete] /back/record/{recordId}”
这叫遵循 REST 了？资源描述清晰么？ URL 设计合理么？

脱离实际问题，一直在自己有限的认知领域里纠结，转圈圈，正如楼上有人说的：“非要把 restful 当成圣经一样是不是傻？搞得自己弄个 restful 就高人一等一样。”

REST 还要求面向资源设计 path
究竟是：
/brand/{brand_id}/reseller/{seller_id}/car/{car_id}
还是：
/reseller/{seller_id}/brand/{brand_id}/car/{car_id}
还是：
/car/{brand_id}/{seller_id}/{car_id}
更好呢？
如果我要取消一个订单，究竟有 PUT，还是 PATCH，还是 POST，还是 DELETE 呢？
哪个才是好，哪个才是烂呢？如果这个是公开 API，那么请问业界用哪个作为标准呢？

规范，是用来降低沟通理解成本的。抱紧 REST 圣经，忘了本来的目的。
我对好的公开 API 的定义是，我只要看懂其中一两个 API，其他 API 我都基本能看懂了。

PS：proto 定义接口了解下，REST 不是唯一的出路。

[hantsy]

@index90 嗯，“规范，是用来降低沟通理解成本的”这个没错。

我不懂了，是能用 PUT，DELETE 表达的地方为什么不用呢？我有说过所有地方都要刻意套用 PUT，DELETE 吗？

Proto 只是在传输方式或格式上作文章，不是 REST 对立和竞争的。在系统内部嘛，太多的东西可以选择，基于 message 方式几乎我能用上就用了。

那么在对外的 API 上，你能告诉是大家愿意接受 REST，还是 Proto ？我是没有用在外部暴露 API 时用过 Proto 了，请示例一下。

[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]

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

[nekoneko]

@murmur #89 我记得有人删除功能用的 GET 请求, 被爬虫把数据删完了