这个其实无所谓。只是要记得在使用幂等 method 的时候，nginx 默认会超时重试。。。

可以在 API 前加个前缀，避免在 history 模式下前端路由和 API 地址冲突。

老老实实地用 RPC Style 吧 Rest 可以滚进教科书里面了

就打个比方

/account/query?

你们产品要求新用户自动创建一个账号 并且在用户侧也提供了隐私&法律信息

你们前端 后端该怎么理解这个 URL ？

到底是写接口还是查接口？

@javaisthebest 哈哈~~ 太真实。 让我想起了 DELETE /user/session/123123123 。 说到底，rest 还是不适合复杂情景。

楼上一群说 RESTful API 缺陷的，你们到底理不理解这个东西究竟是什么，解决的问题是什么。先学会正确使用这个东西才来谈它的缺陷。
如果你的 API 是面向浏览器而且是自包含的，我仍然建议你上 RESTful API 。如果你们的团队完全不理解基于资源的 URI Schema 设计. 那就选择 RPC 吧，比较这个玩意不需要动脑子。

老老实实 rpc 吧，rest 都最后都是一团糟。

rest 的前提是先搞懂 rest ，表格里的列表和查询本就是一个接口/content ，如果需要搜索或排序的话直接在接口上加参数就可以了
rest 的请求方法定义的是动作，url 对应的是资源，组成一个动宾结构的接口形式，当语义复杂的情况只要定义好资源是什么，很方便就能定义出 url 的格式，如果前后端无法达成对 rest 一致的认知，那趁早放飞，免得进退两难

@xiang0818 是的,只是一个路径风格而已,到了服务器都是一样的. 幂等是要注意的,网络是不能相信的

@caisanli /content/create 与/api/content/create 的区分 谢谢提醒

@javaisthebest 这个又到了比写代码还花时间的时候了,我应该把他放在哪合适.我应该叫他什么名字.

@thinkershare 看到的许多博文,大部分都是根据 rest 方式做的分析.所以很想知道这种方式的优势. 如果 api 是面向的还有 app,小程序之的,也适合 RESTful API 风格吗.

@zidian 之前都是用的似 rpc 方式,感觉换成 rest,像改变行为习惯一样. 没弄好,是会弄得一团糟.

@dddd1919 谢谢指出,短短几句比看几篇博文用处更大. 刚又重翻了一篇 rest 看了下, 更感觉这个 rest 像分了类的 graphql. 如果是复杂的语义,只要对参数下手就行了

@dnjat 如果对你来说，HTTP 协议只是一个传输协议，就像 GRPC 使用 HTTP2 一样，那么这种风格对你来说没什么用处。RESTful API 是个很复杂的东西，它涉及到了最初 HTTP 协议的思想和 WWW 最初诞生的一切都是超链接的理想状态。URI 的设计其实是个复杂的话题，远非很多人想的那么简单。RESTful API 是 HTTP 协议最初的设计者希望人们使用 HTTP 的方式。理想很丰满，显示很骨感，大家都抛弃了 HTTP 本身的很多特性，决定 POST 一把梭，甚至没几个完整看过 MDN 的 HTTP 协议的介绍。如果要想要搞清楚这个问题，需要先研究 HTTP 协议（ MDN 的内容就已经够了），如果还想深入理解，最好去看 RESTful API 作者的博士论文。
另外如果你的程序并不是面向资源，而是本质上就是一个 RPC 模式，前端就是一个 Application,目的就是要发送执行命令调用，用谓词结构的确是最节约时间的。
如果你的 API 有很多消费者，是面向大众的，有很多客户需要消费你的 API, 那无论是否使用 RESTful API ，你都要好好考虑怎么设计一个文档的 API URI.

作为一个前端程序员，我发现我写的后端接口是 RPC 风格的，因为 PHP 有两个很好用的超级变量 $_GET $_POST 而并没有什么 $_PUT

@thinkershare 非常谢谢,我再去深入了解下 rest 起源. 和名字挂边的最麻烦了

@impaul put 也是用的 post body 传输方式,delete 用的 url 传值方式. 没用过 php,猜想应该也能用$_GET 和$_POST 获取

我的建议是有条件直接上 Graphql 。
不要理睬那些 Resuful 原教旨主义者。

@YuJianrong 好早啊,莫非在看 ti? 一看你就是 graphql 的受益者,当时一看到 graphql 的统一入口就惊呆了,心想这得多麻烦,全放到一个入口路由.不过他的自由查询还是很喜欢的.

个人主观提倡：RESTful API

更加优雅

rest 非常适合 s3 这种跟"资源"概念强关联的业务。

但它不适合很多的其他场景。。

@AquanllR rest 是非常简洁,聚合强

@flyqie 赞同,看场景.