@Mitt

如果你的 API 使用者都是自己公司的，你这么做当然很 OK ，怎么任性也不会直接扣你钱。

但是重构这种事情，不是 RESTful 就有其他 API 就没有的。 而 RESTful 可以有版本，甚至你还可以给资源起一个新名字，然后将请求 forward 过去。善用 URL 就是有这么大的好处。

你自己设计一套 API 接口，要么按这个套路，要么不兼容以前的调用。
如果 API 里面没有 URL 没有版本这个概念，升级就够你烦的了。
那说来说去，还是说明 RESTful 的已经想得够多了，不像很多人以为的那么肤浅。

@cnt2ex

你说得对， C/C++ 自身不是强类型的。但实际开发中我们很喜欢用它们的强类型特性。
所以不妨视作强类型的吧？

@wizardforcel

你说 99%的都是那么做我是信的，因为 99% 的公司都没有机会有上每天百万级别的 api 调用次数，要协调近百人的 team 来维持 api 服务。

算啦，知道你不服气。正面回应你吧。

你一直在说 http api 调度代价大，事实上数据库访问的代价更大，连接数基本上都是有上限限制的。数据库的调用逻辑更是测了又测。我扩张几台几十台 http server 简直是简单得不要不要的。再况且，我们这里背后的数据库是 mysql 代理，并不是什么 feature 都能支持，你随随便便搞个 DAO 还真不能保证 100%能用。

要是你选你也会选我一样的做法。

@wizardforcel

天真。你以为 任何层的服务器应用都能调用 DAO 访问数据库吗？看样子你根本没做过严格的系统，都是搞些什么 login reg 之类的小社区吧

@wizardforcel

/login /reg /transfer
你能用这种方式设计这些 api ，恰好说明了你的业务不需要把这些行为视作资源。
如果你需要满足这些需求的时候，你就自然要用 restful 了

1. 查询某用户在某时段内的 login 记录
2. 针对某些注册申请进行人工审核，或者拒绝或者 forward
3. transfer 是异步的，需要实时关注 transfer 是否完成

你没有这些需求，你当然不需要把这些视作资源。

关于“为什么要在 HTTP API 里面调用 HTTP API ”
没有为什么，我不关心实现，因为这只是为了适应低能的客户端，怎么实现是业务需要问题。
至于为什么 HTTP API 调用 HTTP API ，那是因为 do not repeat your self. 当这些被调用的 更底层 API 实现有变动的时候，你不需要改高层 API 的实现，虽然这也不一定是必须的。
你连这个道理都不懂，我感觉我们的层次有差距啊。

@magict4

我觉得设计 restful api 的时候很重要的一点是，要弄清楚业务理念哪些概念是原子性的，哪些操作是可以通过多个对原子性概念的操作组合出来的。

如果你觉得让客户端来做这些原子性动作组合，是要求太高，那么你可以加一层 api 来接收客户端的意图，然后在这层 api 之下实现业务，

这样通常能解决很多所谓 fit 进 restful 的问题

本条评论没有帮助。

我就喜欢楼主这样直接的土豪，直接开价，充分表达了对自己时间重要性的评价和对对方专业素养的尊重。

土豪常上来啊

@ShiningRay

猜错了，第一版后端是我写的， restful 很爽。现在我主攻客户端，后端业务升级给了另外一个人，所以我才会集中吐槽不用 restful 会给客户端带来多大的麻烦？

@baconrad

1 和 2 是不可能的因为服务器已经返回 404 了所以肯定网络没有问题

3 和 4 都有可能

@Balthild

你要说优雅，那你优雅的标准是什么？举个例子都没有，我很难跟你说话哦。

又说请求的东西不是资源，什么东西不能视作资源来被管理呢？除了无限的东西之外。

你没有办法用合适的方式把要管理的东西视作资源
——我见到的很多程序员都这样，例如楼上某层不知道事务怎么用资源视觉来处理——
就说 RESTful 不优雅，这是拒绝承认自己有问题。

对于下载 bt 都不愿意做种， emule 也只用吸血版的国人，指望什么去中心化通信软件？我觉得我们还不配。

再有一个就是审查与和谐的需要，写这种软件不光无收益，简直就是赌上身家前途换个身后名。

@Sight4

1. 因为很多人根本没有操刀设计 API 的水平。别说 RESTful 了，我厂也算知名互联网企业，某 C++ SDK 出品一样是个渣渣。 RESTful 要考虑的更多难度更高，但说 RESTful 会导致实现别扭…… 呵呵

2. HTTP 返回码和 回复里面的返回码，通常其含义不应该是冲突的，诸如 HTTP 200 但是 "code": 404 这种只能说某些人自以为很了解 HTTP 协议及其客户端。


3. 不用 HTTP method ，那么基本上就是把动作写在 URL 里面，这种设计我觉得见仁见智，有些时候是很省事，但通常深挖一下就会发现是解耦不够。
更重要的是，这基本上等于放弃了各种 RESTful client SDK 带来的好处。
那还不如直接点干脆不用 HTTP

所以我觉得你说了很多没有经过深入思考的经验，但基本上是废话。

@msg7086

漏了回复你。
对于某些浏览器不支持 GET POST 之外的动作，可以用 http method override

@PhilC

在我那个实现里面， POST Transaction 的时候大多数情况下返回 200 以及事务 ID
然后根据 事务 ID 查询 事务状态的时候，会给出事务的状态、结果什么的。

当然，这个设计是有不足之处的，例如 事务里面的前后两条如果有输出间的依赖关系的话，目前是实现不了的。
但是，你举的这个例子也太 TM 弱智了吧……？

@menc

https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request

所以并不是只针对 URL 的。
事实上 HTTP 405 Method Not Allowed 就是针对你的说法的反例。

@PhilC 里面的 JSON 是手打的，确实是格式不对。
但 POST 一个 JSON 有什么问题么？ 为什么觉得不是 RESTful ？

@Balthild

请举一个 HTTP 上更优雅的设计风格。

@neutrino

“动态处理的内容不应当缓存”？ 明明基于 HTTP 动作、状态码和特定 HTTP 头就能实现的事情，硬生生因为你非要返回 200 而自废武功。

“每一个 url 都应当是实际存在的文件” —— HTTP 3XX 也可以不用了是吧？

所以你这是把规范的实现的效果，在写代码的时候实践了一遍
还不如老老实实遵守全套的 RESTful 规范呢