这是个啥风格的 api 啊?

[ChiangKaishek]

整个就一个 /api 接口, 请求方法全写在负载里面 这样写 api 有啥好处吗?

[fuxkcsdn]

soap 接口很多这样的，这种好处是不用费劲给接口起名，对接起来也挺方便的

以前接携程一个接口，所有的接口名都是 UUID ，具体啥功能看说明文档

[sunhelter]

在 RESTful 概念没出来的时候的写法

[murmur]

@dcsuibian restful 对于水平一般的团队，副作用大于好处，post 和 get 都玩不明白你指望 put 和 delete ？

[muzuiget]

这是很正常也很流行的用法，HTTP 无非就是一个“容器”协议而已。

序列化成 JSON ，传递的是结构化带类型的参数，就像你图中那个 offset 是一个数字类型，order 是一个字典（复杂数据类型），服务端收到一个 JSON 字符串，可以反序列化直接使用，甚至可以用 JSON Schema 这种东西直接检查数据有效性。

你想想如果如果用 get 方法你要怎么传这种参数？是不是要一个个参数取出来？取出来的是字符串，还要手动类型强制转换。

把 HTTP 当成“容器”协议，以后添加和转换协议也很方便，比如 WebSocket/Socket ，只需要加一层简单的“转换器”。甚至可以加密，即防止别人用 DevTools 来逆向工程，好处多多。

所以只要你的业务和 HTTP 没什么强关系，用这种方法更好。

[muzuiget]

@murmur 我也是 restful 黑，restful 不 restful 都一股玄学味道，有那个功夫学习 restful 的理念，早用 JSON 这种东西搞定下班了。

[sivacohan]

rpc 风格
可以看一下 soap ，xml-rpc

[wanguorui123]

JSON-RPC 协议

[dcsuibian]

@murmur Restful 除了设计难点没看出有啥副作用。

put 、delete 、Restful 也不是重点，重点是统一。
没有 restful ，接口设计只会更加千奇百怪，你永远不知道合作的程序员用的是怎样的脑回路。。。

[dusu]

对于 waf 或者基于 accesslog 做统计的系统完全就是灾难

[nothingistrue]

去 HTTP 纯 Application Interface 风格的接口，好处是完全去掉了 HTTP 的影响，缺点是 HTTP 的好处——Header 、缓存、通用等——一个也用不了。

[chocotan]

@dzdh 阿里接口早就这样了......比 spring cloud 早好几年......

[chocotan]

就是网关层的统一入口

[Envov]

我们云 api 也这样，感觉没有什么好处也没什么坏处