推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 859 天前的主题，其中的信息可能已经有所发展或是发生改变。
整个就一个 /api 接口, 请求方法全写在负载里面 这样写 api 有啥好处吗?
 |
1
murmur 2022-08-15 16:57:25 +08:00
get 方法的 post+json 写法，因为写 www.example.com/api?method=group/list ，首先参数的斜杠要转义有些低端开发是不知道的，徒增烦恼，索性全扔到 post 了，get 部分干干净净什么都不留
全 post 挺好的，能避开很多麻烦 |
|
2
murmur 2022-08-15 16:58:49 +08:00
如果他有框架做网关或者自己实现了单入口 /group/list 和 method=group/list ，本质上没区别
|
 |
3
thetbw 2022-08-15 16:58:55 +08:00
支付宝的接口好像就这样，还有一些移动的接口。那些 to b 的这种蛮多，也不知道为啥
|
 |
4
dzdh 2022-08-15 16:59:44 +08:00
支付宝：
https://openapi.alipay.com/gateway.do?method=xxx.xxx.xxx&biz_content=json 阿里云： https://{PRODUCT}.console.aliyun.com/data/api.json?action=ApiName |
|
5
dzdh 2022-08-15 17:00:14 +08:00  1
阿里基于 springcloudgateway 那一套搞的
|
|
6
murmur 2022-08-15 17:00:31 +08:00
@thetbw 多少年前的，大概是 php 年代就开始用的单一入口，那个时候还没有拦截器这么先进的东西，框架页不完善，要自己做一个入口，权限什么的做一做然后分发到业务下，所以路由部分是参数不是 url
|
 |
7
zhuweiyou 2022-08-15 17:01:29 +08:00
websocket 一般这么玩.
|
|
8
murmur 2022-08-15 17:02:45 +08:00
@dzdh 你仔细看，支付宝的页面是做了 IE6 的兼容的，这系统如果是 spring gateway ，除非是我 java 历史需要恶补，不是太超前了
|
 |
9
Onlyil 2022-08-15 17:07:30 +08:00
网关层统一接入吧，之前公司也是这样
|
 |
10
brader 2022-08-15 17:08:33 +08:00
类似这种风格，我上次接入 ETH 的 JSON-RPC API 的时候遇到过，https://ethereum.org/en/developers/docs/apis/json-rpc/
感觉没有什么吧，一样用。 然后关于你说的全部请求使用 POST ，其实大部分请求都可以使用 post ，但是有一小部分请求你不得不使用 get ，就是那种需要通过 url 传递参数的场景，比如你分享一个链接给别人之类的 |
 |
11
Tink 2022-08-15 17:09:05 +08:00 via Android
有这样的，以前我们项目就是这么写的
|
 |
12
westoy 2022-08-15 17:16:30 +08:00
介于 web rpc 和 rest 中间的一种风格
|
 |
14
eason1874 2022-08-15 17:28:08 +08:00
十几年前，虚拟主机时代，CMS 都这样，现在属于是文艺复兴了。不同的是以前没有网关，现在是有网关，而且是可编程网关
|
 |
15
ChiangKaishek OP @murmur #2 感觉这样好像也没给前后端带来啥好处, 接口可读性感觉还差了.
|
|
17
dzdh 2022-08-15 17:43:20 +08:00
|
 |
18
dcsuibian 2022-08-15 17:59:02 +08:00 3
别研究了，这有个鸡儿好处，就是在重新发明 http 罢了
这个 method 明显是拿来做请求分发的——正常直接用 url 就好了，offset 、pageSize 其实用 get 放查询参数里更好。 设计这个的人可能不太了解 http 、restful ，可能是个人喜好，可能是从老师傅那里抄过来的等等。 不是什么大事，毕竟谁还没重复造过轮子呢。 |
|
19
ChiangKaishek OP @Tink 啥情况下要这样写接口啊？
|
 |
20
bk201 2022-08-15 18:01:12 +08:00
方便拦截处理吧，放在 path 部分可能不能严格要求格式。
|
 |
21
fuxkcsdn 2022-08-15 18:08:36 +08:00
soap 接口很多这样的，这种好处是不用费劲给接口起名，对接起来也挺方便的
以前接携程一个接口，所有的接口名都是 UUID ，具体啥功能看说明文档 |
 |
22
sunhelter 2022-08-15 18:09:41 +08:00
在 RESTful 概念没出来的时候的写法
|
|
23
murmur 2022-08-15 18:10:16 +08:00
@dcsuibian restful 对于水平一般的团队，副作用大于好处，post 和 get 都玩不明白你指望 put 和 delete ？
|
 |
24
muzuiget 2022-08-15 18:26:18 +08:00 1
这是很正常也很流行的用法，HTTP 无非就是一个“容器”协议而已。
序列化成 JSON ，传递的是结构化带类型的参数，就像你图中那个 offset 是一个数字类型，order 是一个字典（复杂数据类型），服务端收到一个 JSON 字符串，可以反序列化直接使用，甚至可以用 JSON Schema 这种东西直接检查数据有效性。 你想想如果如果用 get 方法你要怎么传这种参数？是不是要一个个参数取出来？取出来的是字符串，还要手动类型强制转换。 把 HTTP 当成“容器”协议，以后添加和转换协议也很方便，比如 WebSocket/Socket ，只需要加一层简单的“转换器”。甚至可以加密，即防止别人用 DevTools 来逆向工程，好处多多。 所以只要你的业务和 HTTP 没什么强关系，用这种方法更好。 |
|
25
muzuiget 2022-08-15 18:29:33 +08:00 2
@murmur 我也是 restful 黑，restful 不 restful 都一股玄学味道，有那个功夫学习 restful 的理念，早用 JSON 这种东西搞定下班了。
|
 |
26
sivacohan 2022-08-15 19:07:07 +08:00 via iPhone
rpc 风格
可以看一下 soap ，xml-rpc |
 |
27
wanguorui123 2022-08-15 20:56:37 +08:00
JSON-RPC 协议
|
|
28
dcsuibian 2022-08-15 21:41:31 +08:00
@murmur Restful 除了设计难点没看出有啥副作用。
put 、delete 、Restful 也不是重点，重点是统一。 没有 restful ，接口设计只会更加千奇百怪，你永远不知道合作的程序员用的是怎样的脑回路。。。 |
 |
29
dusu 2022-08-16 03:01:43 +08:00 via iPhone
对于 waf 或者基于 accesslog 做统计的系统完全就是灾难
|
 |
30
nothingistrue 2022-08-16 10:07:10 +08:00 2
去 HTTP 纯 Application Interface 风格的接口，好处是完全去掉了 HTTP 的影响，缺点是 HTTP 的好处——Header 、缓存、通用等——一个也用不了。
|
 |
32
chocotan 2022-08-16 13:15:37 +08:00
就是网关层的统一入口
|
 |
33
Envov 2022-08-16 13:40:01 +08:00 via iPhone
我们云 api 也这样，感觉没有什么好处也没什么坏处
|
Select Language