不使用 CF 直接用 Bsd socket 恐怕写异步比较麻烦吧？

Windows10 有 Linux 子系统了

@Balthild

那是因为我给了一把索尔的锤子。当然可以把所有东西当钉子了咯。
事务和队列确实是业务需求，跟 RESTful 无关。
因为你不知道实际上我做的事情是用 json 做了一个 DSL 来描述事务。
这的确跟 RESTful 没有直接的关系。
但如果不是 RESTful 的方式解构所有资源操作，你根本就不可能像我那样用 JSON 来描述所有的事务动作。
你必须一个一个事务地去实现而不是像我写的那个系统那样，把要做的事务交给调用者来定义。
跟你们这些靠勤奋的锤子比，我都不好意思了。

@lslqtz

我只是举了在我那个系统里面的做法为例子，并且是针对带有事务性质的要求，用基本动作的组合来描述一个事务。
没有人说过 RESTful 语义做那种看起来是多个请求组合的方式就真的一定要发多个请求。
既然你可以说的出“ move copy 等请求”
想必用 RESTful 语义 POST a move POST a copy 也不是什么难题吧？

@lslqtz

不明白为什么 RESTful 对你来说居然是代表着多次请求才能完成普通 HTTP 请求。
或许你就是哪种又不懂又要（有意或无意地）泼脏水的
果然无知就是罪恶啊。

@hysterin

讲道理的话，我这种撕的手段只能在 v2 生存。因为这里的立场是讲有帮助的内容。

遇到像你这样的回复，我肯定没招。完全是天外飞仙的歪楼，而在别处不一定属于禁手。

@Cbdy 我相信本帖种不少人表达了类似的意思，甚至说， GET 都不是必须的，有 POST 就够了。

@Balthild @baconrad

你看，我讨论问题的诚意在这里。
我给出了一个例子，展开了这个例子，然后根据这个例子讲了我的看法。
有人提出不同意见
我反驳。

而你们做了什么呢？
只是在把一些看起来很有道理的话贴出来
说了什么很有道理的话呢？
“ XX 是好的，可是不是什么时候都是好的”
“人是肯定会死的，但是不要急着去死。”

不如我也送你一句话：
解放思想，实事求是

不用谢

@wizardforcel

0. 数据库机器比 HTTP SERVER 价格贵得多。

1. 当我增加面向客户的机器时，如果这些机器是纯粹的 HTTP SERVER ，那我就不需要考虑调整数据库集群，但同时带来更好的处理 客户请求的响应性能。

2. 如果这些 HTTP SERVER 我能确保它们实现业务的时候，正确理解和使用 HTTP STATUS 语义，例如 GET 是幂等的， 200 就肯定是成功，这样的语义，那我就能确信它们能降发挥 CDN 的作用降低数据库压力。

3. 遵守 RESTful 的规范确保 这些 HTTP SERVER 能够满足 2.

所以没错，事实就是这么直接，信不信由你，现行的标准里面 RESTful 在集群上就是这么有效果。

@wizardforcel

我说了很多次，也贴了 Google Amazon 的做法，我不介意再重新说明一次我的观点：
*** 自定义错误码是不够的，必须结合 HTTP STATUS ***

而我帖子里面举的例子， GET POST 返回 200 然后 json 说有错这种做法，就是违背 HTTP 语义乱来的做法。
情形就好像 TCP 里面明明发了 ACK 却想要对方重新发送一样鬼扯。

“至于 C/C++ 嘛，在互联网的服务端 /客户端中占得比重太少了”
当我说客户端的时候，你想到的是手机、浏览器；
而我想到的还有 Proxy SERVER ， CDN Server
你只关心业务，我关心的是整个网络上的机器。
所以视野不同，结论不同。
如果算上我说的，你还会认为“ C/C++ 在互联网的服务端 /客户端中占得比重太少”吗？

@wizardforcel

谁强迫你了？谁布道了？
我在批评乱改 RESTful 规范然后又搞出自以为高明的设计。

选择权很重要？
我们不聊政治，按需遵守规范就是降低效率浪费人力浪费金钱，我觉得这些比什么鸟什子选择权重要得多。

@cxe2v

1. 前后什么内容什么观点矛盾了请指出。要不你看看 #123 是不是你自己误读了。说话说一半神惹人烦

2. 什么实际情况请说明，别装 B ，说话说一半神惹人烦。

3. 微信的接口确实没啥牛逼的。各家 sns 的 api 封装是我曾经做过的产品之一，各位写移动 app 调用的 sdk 可能有可能包含我的代码。所以我觉得我起码有调查过，你说它牛逼就因为它是微信？

@danielmiao

我知道你为什么会这么理解我的观点了。

明确一下我的观点：
0. 我反对只用 GET POST
1. 如果只用 GET POST ，那么 GET 一个资源 ID 错了的时候用 404 会有歧义
2. 如果不希望客户端错误理解 404 （并且将错就错），那么返回 200 和 一个 JSON 应该是可行的做法
3. 可是这样就必须强迫客户端总是要解析 JSON ，并且如果真的是资源不存在的时候， HTTP 设备也无法知晓

所以 3 就只用 GET POST 这种方式带来的隐忧，也因为如此我反对这种设计。

@cxe2v

反正 v2 上发了帖就改不了。你愿意指出具体问题你就说，不想认真就别回。

你要说 RESTful 规范不适合的时候强行用，真是好笑了——我做了什么 RESTful 的系统，又是怎么不适合的？
或者我举了哪个例子，让你觉得 RESTful 不合适？
怎么不合适你又不说，不好意思，不是你女朋友你老婆，我不负责体贴你。

既然我举的例子你不服，觉得微信是王道，你说出个微信的道理来，有没有理大家评评嘛。

觉得说不过、不值得提前撤，也是可以的。
接受我的奚落就是了。

@cxe2v 知道你是这种水平之后，我也不稀罕你的赞了。

@cxe2v

请问我偷换了什么概念？


这是 AWS 的：

REST Error Responses

When there is an error, the header information contains:

* Content-Type: application/xml
* An appropriate 3xx, 4xx, or 5xx HTTP status code

The body or the response also contains information about the error. The following sample error response shows the structure of response elements common to all REST error responses.


这是 google 的：


The Drive API returns two levels of error information:

HTTP error codes and messages in the header
A JSON object in the response body with additional details that can help you determine how to handle the error.
The rest of this page provides a reference of Drive errors, with some guidance on how to handle them in your app.


难道我在 #115 表达的不是这个意思？

@danielmiao

你的回复居然获得了一个赞，我很嫉妒，所以我再提供多一个简单的测试方法好了。
如果你想知道 404 是谁搞出来的。
curl -i 就可以看到是哪个服务器发出来的响应了。
真心不理解为什么会难测难发现。

@danielmiao

这种 NG 配置错误的问题，要影响服务 API 设计工作吗？很难发现或者测出来吗？
单元测试 RESTful 接口不通过 HTTP 调用……请问你们是怎么测？
如果上司让你们因为这些低级错误改设计的话那你换公司好了。

我再重申一下观点， RESTful 是工作在 HTTP 之上的，而且是与业务具体相关的协议
所以肯定是有 HTTP 状态和业务状态两个概念。
当然错误码也会有 HTTP 错误码 和 业务专有错误码，
HTTP 错误码是为工作在 HTTP 层的各路非业务设备看的
业务专有错误码是工作在业务端的，两者只要不含有意义冲突的定义。

转帖一下大厂怎么设计 RESTful 错误码

http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
https://developers.google.com/drive/v3/web/handle-errors

@danielmiao

首先，如果是负载均衡有问题，你们确定是返回 404 吗？
按我的经验，如果负载均衡是 Nginx 做的话，应该会是 503 或者 504 ， 明确指出了这是服务端的问题。
如果是客户端方面得到了错的 URL 那么 就是 4XX 可能是 404 也可能是 405.
HTTP 的状态码本身就明确区分了责任方。

第二， RESTful 并不拒绝自定义错误码，只是必须要与 HTTP 状态码意义不冲突
事实上 AWS GCE 的 RESTful API 文档里面也定义了大量的自定义错误码。
习惯的做法是用 Json Envelope ，将适用的真正要返回的数据封装在一个公共知晓的结构里面。
怎么可以说 RESTful 没有异常的概念呢？

请确定你有了解清楚 RESTful 的内容，例如本贴中 #39 给出了一个不错的参考来源,其中就有提到：
“ Don't use an envelope by default, but make it possible when needed ”

这怎么能说它不支持异常呢？
讲道理的话， 3XX ， 4XX 5XX 都能算作是异常。