对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全
caicaiwoshishui · 2022-01-23 10:29:15 +08:00 via iPhone · 25583 次点击这是一个创建于 1060 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前习惯使用 restful api ，如果说 https 只有 post 请求是安全的话？那为啥还需要 get 、put 、delete ？我该如何反驳他。
 |
1
JamesMackerel 2022-01-23 10:33:11 +08:00 via iPhone  34
post 是最好的，我也全部用 post 。大环境用什么就用什么，早点搞完早点回家抱老婆。
|
 |
2
InDom 2022-01-23 10:41:16 +08:00 6
吵赢了对你有什么好处？
|
 |
3
caicaiwoshishui OP 2
@InDom 如果业界都这样，那无话可说。
|
 |
4
infun 2022-01-23 10:49:30 +08:00 via Android
从实践角度来说 post 一把梭 没啥问题
|
 |
5
pengtdyd 2022-01-23 10:50:39 +08:00 2
说 post 安全的简直是自欺欺人
|
 |
6
raycool 2022-01-23 10:51:43 +08:00
感觉这种争不出来什么最优结果。
|
 |
7
changdy 2022-01-23 10:52:49 +08:00 6
emmmmmm 这样子说 不知道你能不能接受
1 1 楼说的` 早点搞完早点回家抱老婆`是对的 2 2 楼说的是实话, 自我追求最好放到自己的项目里 3 即便赢了 他的`restful` 可能你也会崩溃 4 复杂系统大部分人的 restful 也是四不像 |
 |
8
0ZXYDDu796nVCFxq 2022-01-23 10:54:24 +08:00
对于同一个资源，GET 和 POST 如何区分？
GET /api/user/name POST /api/user/name 这两个不用区分吗 |
 |
9
bug123 2022-01-23 10:54:39 +08:00 1
实际上就是，别不承认了，虽然理论上不是。
举个我以前遇到的例子，在浏览器上访问了一个外网 url ，几天后这个 url 就被搜索引擎收录了，如果是 post 就不会出现这个问题 |
 |
10
xianyu191031 2022-01-23 10:55:14 +08:00
全用 post 的压测不得疯？你都不知道这接口到底有没有写操作
|
 |
11
takato 2022-01-23 10:55:30 +08:00
想请教一下这个问题：
为什么在 HTTPS 下 POST 请求更安全呢？ |
 |
12
nicevar 2022-01-23 10:55:55 +08:00 2
post 一把梭太多了，没什么问题，争论这个没太大意义，就像争论中午吃米饭还是吃馒头一样，你为什么要吃米饭，那为啥还要馒头？你真想硬刚，两人走一个，这是最好的解决办法，
|
 |
13
liuzhaowei55 2022-01-23 10:57:57 +08:00 via Android 3
纯 post 真的好用，一把梭，少了很多沟通成本
|
 |
14
misaka19000 2022-01-23 10:59:51 +08:00
远离这种自以为是的同事
|
 |
15
aababc 2022-01-23 11:01:07 +08:00 1
至少应该区分 POST 和 GET 吧，全用 POST 想不明白为啥？虽然 HTTP 没有明确的规范，但是最基本的通用的常识应还需要有吧。
|
 |
16
kran 2022-01-23 11:02:33 +08:00 via Android 2
这个我和朋友讨论过，从安全方面看有一点很重要，post 请求不会在请求日志中留下敏感参数
|
 |
17
PDX 2022-01-23 11:03:32 +08:00 via iPhone
为什么 post 安全……？是因为除了 url 全加密？
|
 |
18
Smilencer 2022-01-23 11:07:22 +08:00 via iPhone 7
全 post 挺好呀，你遇到全 get 的吗？哈哈哈哈嗝
|
 |
19
chendy 2022-01-23 11:09:23 +08:00 3
工作而已，除非你是架构 /领导，否则接就完事了
优雅不能当饭吃，除非有性能 /安全隐患，否则早点弄完早点回家才是最吼的 |
 |
20
Chism 2022-01-23 11:14:51 +08:00 via Android 1
确实更安全，post 不会被搜索引擎收录，get 会
|
 |
21
leafre 2022-01-23 11:14:53 +08:00
首先你的 URL 符合 restful 规范吗？不符合就不要强求后端遵守规范，毕竟规范只是规范不具有强制性
no restful : POST /login 和 POST /logout restful : POST /sessions 和 DELETE /sessions |
 |
22
hlwjia 2022-01-23 11:15:32 +08:00
@changdy 说得好，另外就是
对错的事情，都有前提条件的，如果赶着上线，要让后端按照 restful 规范改，那就是错的。 如果单单只是说“只有 post 是安全的”，那也是错的。 你心里知道 restful 是怎么一回事就可以，最好的办法是辞职去一个遵守 restful 的团队。 |
 |
23
Wuuuu 2022-01-23 11:16:34 +08:00
借楼求问下，现在我们就是 POST 一把梭，因为比如有一列表数据，返回给前端，要求能自定义分页，能 filter 所有字段，能 sort 所有字段，filter 时间类型的可能还要判断 大于，小于，大于或者 between 。字段可能有 10+的数量，这种 GET 请求写起来有什么好方法么。
|
 |
24
star7th 2022-01-23 11:16:54 +08:00 2
全 post 没问题。对前后端来讲都省事很多。我反而非常不同意标准的 restful api 使用 http 状态码来跟业务耦合。我觉得 http 协议应该解决的是系统层面的东西。业务的东西都应该放在 header 或者 body
|
|
25
hlwjia 2022-01-23 11:19:35 +08:00 1
|
|
26
leafre 2022-01-23 11:20:36 +08:00 2
@leafre 还有 restful 针对只有增删改查的业务来说很合适，当复杂业务 restful 那几种明显是不够的，强行使用反而导致 API 不直观清晰，导致混乱
|
|
27
liuzhaowei55 2022-01-23 11:20:51 +08:00 via Android 1
@Wuuuu 之前看过完全按照标准来就需要两次请求，一次 post 提交过滤条件，然后返回结果 url ，前端请求这个 url 获取结果
|
|
28
star7th 2022-01-23 11:21:31 +08:00 2
标准的 restful api 在国内无法大范围流行是有它的局限性的。我自己做接口管理方面的工具 showdoc ，https://github.com/star7th/showdoc 我发现完全使用标准 restful api 的公司比例不高。肯定是有，但是比例没有很高，应该不到 20% 。甚至大厂内部也不算多。大部分还是 post/get ，返回 json 这种形式。而且这种形式对前后端代码调用都比较友好。
|
 |
29
seers 2022-01-23 11:22:24 +08:00 via Android
之前在哪看的，post 还是 get 底层都一样，只是强行区别开
|
 |
30
index90 2022-01-23 11:23:00 +08:00 4
HTTPS ，常称为 HTTP over TLS 、HTTP over SSL
严格地讲，HTTPS 并不是一个单独的协议，而是对工作在一加密连接（ TLS 或 SSL ）上的常规 HTTP 协议的称呼。 https://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%AE%89%E5%85%A8%E5%8D%8F%E8%AE%AE 估计你同事以为 HTTPS 是只对 body 进行加密，其他都是明文，而实际上 HTTPS 依然是 HTTP 七层协议，安全是依赖 TCP 层的加密连接。 |
 |
31
HackerJax 2022-01-23 11:24:32 +08:00 via iPhone
@Smilencer 还真遇到全 GET ，理由是：查 apache 日志可以看到 query 参数。哈哈，血压上升的操作
|
 |
32
wheeler 2022-01-23 11:24:37 +08:00 via iPhone 3
@Wuuuu #23 我看见有把 json 塞 url 的。
api/rest/v1/products?search={"enabled":[{"operator":"=","value":true}],"completeness":[{"operator":">","value":70,"scope":"ecommerce"}]} https://api.akeneo.com/documentation/filter.html |
 |
33
darknoll 2022-01-23 11:25:54 +08:00 via Android
说被搜索引擎收录的不知道单页应用这个概念？
|
 |
34
hotsymbol 2022-01-23 11:30:01 +08:00 8
OSWAP 和 PCIDSS 的接口安全规范里面都写了建议全量使用 POST 接口
|
 |
35
labulaka521 2022-01-23 11:47:40 +08:00 3
全 post 接口用 Getxxx/Listxxx/Createxxx/Updatexxx 感觉很好
|
 |
36
Biwood 2022-01-23 11:47:52 +08:00 via iPhone
就事论事，如果没有确凿的证据说明全量 post 不好，那就按对方的来呗，为了反驳而反驳显得很奇怪，只能说知识储备量不够。与其问为什么全部 post 不好，不如问问为什么 get 和 post 分开用更好，对比一下哪一种重要性更高，更符合你的业务模式。
|
 |
37
EPr2hh6LADQWqRVH 2022-01-23 11:55:21 +08:00 16
实际项目中 API 能套进 restful 模型完全是一种偶然，大多数时候没法套进去。
说到底 PUT PATCH DELETE 这些是从 WebDAV 来的，是操作静态文件用的，没法套给抽象概念。 我也不知道谁还在传教 restful,搞得市场上这么多初出茅庐的文革小将，见面就是你这 API 不 restful. 无力吐槽。 |
 |
38
looking0truth 2022-01-23 11:56:19 +08:00
1. 问 leader
2. 听 leader 的 3. 结帖 |
 |
39
Innovatino 2022-01-23 12:00:35 +08:00 via iPhone 3
你可以在简历里面写上这个要求：团队后端接口必须遵循 restful 规范。
求职是双向的，你也可以选择他们 |
 |
40
nvkou 2022-01-23 12:06:30 +08:00 via iPhone
怎么反驳？安全性不由 http 协议提供，完事
|
 |
41
sunhelter 2022-01-23 12:12:14 +08:00 1
看样子社会的毒打还不够多，就效率上来说全用 POST 减少了大量开发成本和沟通成本，更快交付项目。他的理由说错了罢了
|
 |
42
lsdvincent 2022-01-23 12:16:27 +08:00 via iPhone
我们是绝不允许使用这种垃圾技术
|
 |
43
jfcai 2022-01-23 12:19:36 +08:00
见过用 POST ，但所有参数拼接在 URL 上的吗？
|
 |
45
ZSeptember 2022-01-23 12:29:04 +08:00 1
1. 公司或者部门有规范，按照公司规范来，没有的话，公司有点问题，没做好
2. 老项目，按已有的 API 规范来 3. 新项目，看项目能不能达成一致使用 RESTful 风格的 API 设计，不能达成一致，使用 RPC 风格的 API 也不是什么问题 当然，面对说 POST 更安全，这种极其不靠谱的后端，可能及时跑路更好 |
 |
46
Suddoo 2022-01-23 12:29:32 +08:00
我之前的组，强制规定，所有请求全部用 POST
|
 |
47
zpf124 2022-01-23 12:31:43 +08:00 7
https 是传输数据全加密的，除了请求的目标 IP ，中间设备是抓不到任何内容的，path 部分 body 体都一样，除非请求发起端被黑了，信任了中间人的证书，然后被中间人劫持。
（题外话，所以不要在公司的加域电脑或者需要安装上网控制的内网上干私人的事，对于 IT 和老板你 https 了也是光屁股的） 这个后端找借口都不会 ， 我教他俩百分百对的。 "Restful 对于某些业务很难抽象，比如网上各种对注册登录的实现，要么破坏规则与其他 restful 不统一，要么强行把简单的逻辑抽象成了复杂还别扭的规则。" "公司运维有统一请求分析控流组件，每个项目都是统一接入的，而这个组件不支持 url 里的携带变量，要求运维发开升级组件难度很大，影响范围很大并且升级后稳定性无法评估。（或者 这是采购的第三方产品，且除软件外还包含专用防火墙硬件设备，厂家无法支持升级，需要购买新设备替换）"。 |
 |
49
msg7086 2022-01-23 12:36:29 +08:00
说得难听点，你进了愿意招这样的同事的公司，而且你的 leader 默许（或支持）他的做法。
|
|
50
ZSeptember 2022-01-23 12:36:48 +08:00
@avastms #37 RESTful 最重要的是对业务建模，一个资源对应后端一个业务模型，所以其实是能在大部分场景使用的。只是业务模型和前端 UI 并不完全对应，所以前端的时候一般会都套上一层 BFF 。
|
 |
51
prenwang 2022-01-23 12:43:12 +08:00 1
restful 只是个参考规范。 没有哪一条规定说要强制使用这个规范， 项目内统一规范不一定就是 restful
相对来说 post 当然比 get 更安全， 不说收缩引擎收录， 只是在各个网络节点至少不会留下痕迹。 用不用 restful ， 看你的 api 最终用户群， 如果 api 就是那么几个人用， 那就让 restful 见鬼去。 |
 |
52
pcbl 2022-01-23 12:46:09 +08:00 via Android
restful 大多数情况下会变得不伦不类，完全不如 detxxx deletexxx updatexxx
|
 |
53
redeemer1001 2022-01-23 12:47:45 +08:00
PTC 的 Thingworx 平台，自称 RESTful API ，只支持 POST ，我想做区分都不行，就这样吧
|
 |
54
lasuar 2022-01-23 12:52:31 +08:00
同 35 楼 ，全 post 接口用 Getxxx/Listxxx/Createxxx/Updatexxx 感觉很好，别人发个接口给你，从名字就能看出作用
|
 |
55
Wenco 2022-01-23 12:54:36 +08:00
需要通过链接分享的得用 GET ，例如筛选参数，分页等，不过前后端分离的也不存在这种情况了。
其他的如果不是 RESTFUL 风格的，都用 POST 没啥问题。 |
 |
56
adoal 2022-01-23 12:55:24 +08:00 via iPhone
相信我，以后你跟这个同事合作过程中遇到的草台、山寨问题一定会比这更严重
|
 |
57
lanlanye 2022-01-23 12:58:05 +08:00
@Wuuuu 筛选分为相等，排除，比较等形式，添加如 eq lt le gt ge 等标志可解，排序定义一个单独的参数即可。但我认为这只不过是一种接口设计的思路，实际上遵循的思想是 “尽可能少造轮子”，比如利用已存在的 HTTP 状态码代替自己定义错误信息，楼内也有人说了，非增删改查的复杂逻辑是很难用这种方式设计的，所以需要变通，比如当前端把筛选区做成一个很大的表单时，使用 POST 方法提交其实也很合理。
|
 |
58
leeg810312 2022-01-23 13:02:18 +08:00 via Android
现在 get 也可以带 body ，get 和 post 不是一样安全？
|
 |
59
0xsui 2022-01-23 13:08:54 +08:00 via Android 1
@jfcai 见过 url 拼接 sql 的(ؓؒؒؑؑؖؔؓؒؐؐ⁼̴̀ωؘؙؖؕؔؓؒؑؐؕ⁼̴̀ )
|
 |
60
shyangs 2022-01-23 13:12:23 +08:00 3
RESTful 不是標準規範. 沒有遵守的必要.
JSON 有標準，標準文件是 ECMA-404. PNG 有標準，標準文件是 RFC 2083. RESTful 沒有標準規範. 不同的人搞 注冊登錄，會搞出千奇百怪的實現. |
 |
61
Cbdy 2022-01-23 13:13:41 +08:00
他说的是对的
|
 |
62
XCFOX 2022-01-23 13:15:19 +08:00
GraphQL 大法好 https://graphql.cn/
GraphQL 就没有 get 、put 、delete ，全是 post ，根本不纠结。 |
 |
63
aliveyang 2022-01-23 13:16:52 +08:00
就是懒
|
 |
64
cumt21g 2022-01-23 13:17:34 +08:00
我还见过 header 里塞 json 的呢
|
|
65
ZSeptember 2022-01-23 13:19:14 +08:00
@0xsui #59 见过，想骂人，国外的 quickbooks ，API 查询直接写 SQL 。这可是国外流行的财务软件，母公司市值 1500 亿刀，
|
 |
66
h82258652 2022-01-23 13:22:49 +08:00
你应该反驳你同事，POST 还不够的，应该要对参数进行加密，加时间戳，防止回放攻击
|
 |
67
dawniii 2022-01-23 13:23:12 +08:00
全用 post 确实能减少很多沟通成本，请求参数全都用一种固定的 json 格式，这样大家都方便。
get 请求 url 上面携带参数确实会提高一些沟通成本，比如遇到的几个情况： 1. 如果参数是数组，大家要协商用什么形式传递大家都方便处理，不同框架的处理情况可能不一致 2. 如果参数值中有空格或者百分号等会转码的字符，双方的 urldecode 方法和规范要一致 还有几个想不起来了。但是自从全用 post 传递 json ，这些问题都不用沟通了。 |
 |
68
BQsummer 2022-01-23 13:24:36 +08:00 via Android
同意 47 楼。
1. 复杂业务场景按照 restful 设计不可能完全符合 2. 我负责监控告警，把 id 带到 url 上真的很难处理 |
|
69
0xsui 2022-01-23 13:28:15 +08:00 via Android
@ZSeptember 去年看见普联软件一个财务报销线上系统这么玩，大公司系统成型，招毕业实习生就搞出这种怪物(;-_-)ᴇᴍᴍᴍ
|
 |
70
astrorobbie 2022-01-23 13:32:03 +08:00
之前在 IE 里遇到一个问题，如果 GET 请求的参数含有中文，会变成乱码，后来就都用 POST 请求了
|
 |
71
dcsuibian 2022-01-23 13:43:41 +08:00
先不说 restful 的事，“https 用 post 更安全”这个论点是错的。因为 https 里，信息都加密了，外部甚至连用的什么请求方法都不知道，要有问题就是加密前解密后的问题。
比较安全性必须得说清楚原因。 post 比 get 安全是真的，因为请求参数如果放在 url 里，那么浏览器的收藏功能啥的就有可能把这个 url 记录下来，而不是因为 https 传输过程的问题。而且，对于用户名密码这种场景 get 不适用，但对分享链接就很合适（比如搜索引擎，把关键字放在 url 的查询参数就很合适）。因此，对应的场景使用对应的请求方法是有道理的。 但 post 和 put 、patch 什么的，把信息放请求体里就没有这个问题。 |
 |
72
offswitch 2022-01-23 13:48:26 +08:00 via Android
@astrorobbie 这跟 get post 无关，编码问题
|
|
73
0xsui 2022-01-23 13:52:58 +08:00 via Android
@astrorobbie 这种情况 Base64 转一下再传
|
|
74
0xsui 2022-01-23 13:53:33 +08:00 via Android
@astrorobbie 或者 url encode 一下
|
 |
75
Jooooooooo 2022-01-23 13:57:48 +08:00
他的理由不对
他这么用没啥问题, 一把梭挺好的, 也不会带来什么额外成本, 反倒是 get post put delete 乱来, 每个接口还要小心区分, 何苦呢, 也不带来新信息 |
 |
76
mrcode 2022-01-23 13:59:56 +08:00
去年也遇到了个同事全部定义成 POST ，原来是因为底层 RPC 框架省事的原因。。转念一想 POST 确实会少很多坑，如果能克服没对齐规范带来的内疚感没啥大问题，甚至还能避免 URL 过长导致解析出问题的 BUG 。
换个角度说，很多接口喜欢在返回值里添加状态码，那又怎么定义请求失败了呢？查找一个不存在的资源是提示业务的状态码还是 HTTP 规范的？我觉得都不重要，关键是在项目中形成一套规范，方便大家理解就行 |
 |
77
chenzhekl 2022-01-23 14:00:41 +08:00 via Android
全 POST 没什么问题，RESTFUL 也不用这么教条主义。
|
|
78
mrcode 2022-01-23 14:01:45 +08:00
规范本身就是希望节省代码和理解成本，权衡利弊后怎么使用规范完全是研发自己的权利
|
|
79
dcsuibian 2022-01-23 14:03:54 +08:00 5
还有，restful 是个好的参考标准。虽然实际中设计的 api 很难完全符合 restful 标准（有个词叫“反模式”？），但在能使用 restful 的时候就应该使用。
为什么？因为每个人的设计思路都不一样，不遵照一个标准就会遇到各种牛鬼蛇神。 你今天可以抛弃 http method 不用。推而广之： 1 、url 只有一个请求路径字符串，太弱了，我要定义自己的结构，自己写请求分发器发到不同的处理方法。 2 、https 是公开的，安全性不行，我要用自己的加密方法。 3 、反正是传递信息，websocket 双向通讯，不比你 http 强 restful 能在各种 api 设计里脱颖而出，如果真的有人认为自己的接口标准能打败他，那自然更好，赶紧亮出来给大家开开眼。 |
 |
80
ospider 2022-01-23 14:10:37 +08:00 4
感觉 V2 上不看题目，上来就是无脑输出自己观点的也是越来越多了呀。
ls 说的对，他这个理由肯定是不对的，post 更安全顶多是敏感信息不会打在日志里，跟 https 没有半毛钱关系。 即使这样，全部都用 post 也是值得商榷的，这取决于你服务的类型，而不是无脑 post 就对了。 - 对于资源型的服务，或者说 CRUD ，那显然是 Restful 更加语义化一些，全部 post 想想就不是很合理。 - 对于 RPC over http 型的服务，全部使用 post 是值得推荐的，实际上像是 jsonrpc 这种标准定义也都是 post 。 最后，具体选那种方案也得考虑你在这个项目中什么角色，如果不用你维护，就是帮帮忙，那同事愿意咋样就咋样呗。如果最终是你维护，那最好要坚持你的正确意见，不然那不是给自己挖坑么？ 希望 V 友们好好审题啊，别只输出情绪。 |
 |
81
wangyu17455 2022-01-23 14:20:36 +08:00
不用 post 的话,请求的从参数在浏览器的历史记录都能看到,用了 post 就看不见参数了
|
 |
82
aguesuka 2022-01-23 14:44:20 +08:00
post 一把梭有一个厉害的名字叫做 "rpc style", 时髦值不在 "restful" 之下. 你的同事没你有信仰, 建议帮他觉醒成 rpcist, 然后你作为 restist 和他打一架, 谁赢了听谁的.
|
 |
85
learningman 2022-01-23 15:02:18 +08:00
他说啥就是啥，写完回家了
请求 Method 只是 Http 头里一个字符串罢了，你想定义个 FUCK 方法也是可以的 |
 |
86
gengchun 2022-01-23 15:02:32 +08:00
REST API 的定义和实现本来都不是太好。不然也不会有什么 graphQL 之类的事情了。所以实践中分歧才会很大。
不过这个和 POST 没有什么关系。但是使用 POST 一把梭的一个好处是 payload 可以自己再加密一层。这个对来对抗 api 逆向工程是很有用的。大部分强调安全的系统，工程实践上确实直接用 POST 的比较多。我知道不少系统在对抗爬虫的过程中都会演变成纯 POST 。 如果不打算再加密 payload 的话，用 REST API 加上 HTTPS 安全性上确实区分度不大，这个只是对简单的前端系统的开发友好一些罢了。 当然，OP 所说的这个他同事的这个理由有点不对。不过 OP 本来就是在吵架，很可能根本没有理解同事是什么意思。 |
 |
87
MrBearin 2022-01-23 15:11:12 +08:00
都可以, 类似这种问题, 我现在基本已经不怎么和其他人争辩了...团队内大家都认可就好...类似, 命名方式, 要不要用 lombok, 用不用链式 set, 新项目要不要抛弃陈旧的代码格式化规范文件等等...
|
 |
89
jguo 2022-01-23 15:16:42 +08:00
就是接口不是 restful ，只有 post 安全也是 sb 理解
|
 |
90
seanzxx 2022-01-23 15:19:00 +08:00 via iPhone
这也要看他提供的 api 怎么实现的吧，比如 json rpc 就全是 post 呀
|
 |
91
chenyu0532 2022-01-23 15:19:51 +08:00
我是客户端，后端说用什么我就用什么
|
 |
92
Gota 2022-01-23 15:20:25 +08:00 7
我们团队内部早期也经常对 API 定义这种问题争来争去浪费开发时间, 后来有次开会确定下来全部按照 <Google API 设计指南>: https://cloud.google.com/apis/design/ 走, 就再也没有吵过了. 毕竟对于一般团队而言, 你能想到的和想不到的, 他们都踩过坑了.
|
 |
93
preach 2022-01-23 15:24:48 +08:00
理性猜测，post 更安全只是为了给你个理由，并不是他真的想法，而且他并不想浪费时间在解释这件事情上
|
 |
94
wellsc 2022-01-23 15:25:24 +08:00 via iPhone
hyper text transfer protocol ，纯文本传输协议罢了，用啥 method 都没区别
|
 |
95
konakona 2022-01-23 15:37:40 +08:00
他如果直接跟你说是为了 post 一把梭方便，那还好。
如果是“https 用 post 世界第一”，就有点引喷了。 |
 |
96
RuLaiFo 2022-01-23 15:54:26 +08:00 via Android
要么完全遵守 rest 规范，要么就随他们咋用就咋用，除非你有很大的主导权，即使这样不规范。
|
 |
97
xiangyuecn 2022-01-23 15:57:25 +08:00 1
没别的意思，我就是纯粹的想炫技😂 每次看到讨论有 post 一把梭 还是 restful 的，我就想用 xxoo 做 method
前些天刚好写好了代码，这次正好派上用场，ie 里面用 js 代码跑个服务端，通过 xxoo 请求来调用，完美🐶🐶 ----  ----  |
 |
98
ThomasZ 2022-01-23 16:03:36 +08:00
反驳能达到双赢还是你赢，不能，反驳啥？ 人家改接口你喝茶？
|
 |
99
iamsk 2022-01-23 16:04:31 +08:00
自己先认真了解 restful 设计实践，有 Github 、twitter 等这么优秀的可以参考，包括了解安全问题，沟通说服。
即使按 restful 设计也会有很多不同意见，这个过程你们都有学习。 我的理解 restful 毕竟是前人形成的规范指导，大家思考一致，可以节省很多接口理解、测试用例等方面的沟通 而 post 各个公司、各个人的规范和喜好都不同，相当于先大家对齐规范，程序员不要做这种”一次性“的事情 |
 |
100
eason1874 2022-01-23 16:09:18 +08:00 2
讨论技术的时候：扯淡
现实合作的时候：对对对，你说得对 只要别增加太多工作量，说什么都对 |
Select Language