@rayston92 哇，敢用 Rust 做产品，大心脏啊…… 使用密码学原理玩过 blockchain ，简直跟我最近做的事情 90% 重合嘛。 可惜我打死都不敢去北京。

已注册并提问。祝推广成功并大热。

搞定这帮 low 逼的所有疑问并且让他们心悦诚服，你就猛赚到这人群的钱，搞不定上来诉苦的话就赚不到。就这么简单。没有安慰剂，没有鼓励，自己看着办。

需求说得不够明确。虽然你认为不是 Task ，但根据我的理解，你需要的只是一个能够把 continuation 按照顺序执行的方式写出来的库。就算不是 Task 那也是跟他很相近的东西。可以考虑基于，如果 C++用 boost::coroutine ，如果 C# 用 Task 等等来做进一步封装成你需要的东西。

说方言一定全部会消亡的是经验教条主义错误。楼主所做的则是实事求是，准备展示方言如何不会消亡并且取得发展。

典型的多分派行为，不想用模版的话可以考虑 Visitor 模式。

linq 路过，微微一笑。

@Balthild

1. 不说逻辑处理的细节都是在扯淡。如果业务协议都是 GET POST 200 ，要怎么写代码才能知道是未经业务逻辑响应？
难道不需要尝试解析一下报文吗。
一句话轻轻带过，你也就是用用框架写写业务代码的水平。
讨论 REST 太为难你了。

2. 不说人话，我也不想和你讨论了。
请你离开此贴。

@Balthild

1. “调用者会无法判断这个错误是否经过了 API 的业务逻辑才返回的”

很明显这是因为没有正确地使用 HTTP Header 。
调用者只需要分析一下 Content-type 和 Server 头就知道是否经过 API 的业务逻辑。

但说实话，作为 API 调用者的 HTTP Client ，知道是否经过 API 调用这真的重要吗？
这是否意味着调用者与 API 服务之间的过度耦合？
如果确实未经过 API 服务就得到了 HTTP 回复难道调用者就不需要处理了吗？

所以这是一个因为错误的做法而产生的伪问题。
错误的根本原因就在于对 HTTP 的能力了解不足，才会说只要 200 和 GET POST 就够了。

2. 什么叫做“自然的对应法则”？

我不觉得你说的“自然的对应法则” 不适用 “存储位置” 和 “挂载位置” 两种概念中的一种。

你能够 “不把位置视为资源的扩展属性” 那纯粹是业务不需要。

拿 “邮件”作为资源的具体例子，对应“发送”“归档”“删除”“移动”。

你解释一下你的所谓 “自然法则”是什么。
反正我是觉得肯定跑不开 “存储位置” 和 “挂载位置” 这两种。

“存储位置”：邮件数据在物理存储中的位置，无外乎 数据库中，文件系统中
“挂载位置”：邮件属于哪个逻辑存储位置，例如某某用户的某某文件夹下，某某分类或者聚合的某某路径下。

你乐意的话，讲讲你的 GET POST 怎么完成上面的业务概念。

我已经证明过 RESTful 无论应对哪种需求的展开都有完美的办法。

using namespace 不代表引用了那个 namespace ， include 去哪了？

@Balthild

1. 不明白为什么是“类比错误”。

为什么你认为 “用 HTTP StatusCode 来表示错误才是相当于 int GetNumber() ，且用返回之负数的值来区分错误。”
以及“ <int, Error> GetNumber() 则是类似于返回 json 来描述错误”？

没说理由，你太着急反驳我了吧。


2. 你既然有“移动资源位置” 的概念，那肯定本身就有“资源存储位置” 的概念，或者“资源挂载位置” 的概念，两者之少有一个。

所以不存在你说的，“为了套 REST ，你又要特意增加一个「挂载位置」的概念”。
不知道你有什么好装 B 的。


* 针对只有“资源存储位置”概念的系统 -> 做成事务封装两个请，求或者直接发送两个请求，或者再包一层 API 来决定要用哪种方式

总之，物理上改变资源存储位置肯定是两个， API 形式上是一个调用，只不过是选择不让人看到这个事实 ；暴露两个原子的调用接口的 API 设计选择，是选择让调用者知道更多。

这只是一种口味问题，你把这种问题偏离到 “套用 REST ” 只能说明你根本没仔细想过。

* 针对支持“资源挂载位置” 概念的系统 -> 做成修改资源挂载位置的请求 。

支持以上这些， RESTful 都是毫无问题的。

---

为什么我认为 "用 HTTP StatusCode 相当于 返回 Either<int, Error>", 我的理由是：

1. 对所有的使用者来说,结果的理解方式是唯一的，要么 match(int), 要么 match(Error)

2. 对所有获得 HTTP Response 的使用者来说，要么 match 到他关心的 HTTP Status Code ，例如 2XX, 3XX, 4XX
要么 match 到它可能不关心的 match(Error) ，于是处理这个错误时可以不用管 Error 具体是什么（具体错误内容在 Http Response Body 里面，通常是 Json ），这些通常是非业务相关的中间设备，例如缓存服务器， HTTP 网关之类的；
也可以是业务相关的设备，这些设备可以进一步处理 Error 的解析（也就是解析 Response Body 里面的 Json ）


为什么我认为 只使用 GET POST ，相当于返回 int ，

就如同我本帖一开始说的那样，相当于要求所有参与调用这个 API 的人知道， int 的含义并不是简单地一个数值，而是在某个数值范围内才是正常的结果，在某个数值范围内是表示错误。

只使用 GET POST ，
如果不是一直使用 200 ，那么就有混淆资源相关错误和 API 错误的问题；
如果一直只使用 200 ，那么就强迫所有使用者必须了解业务细节才能理解 HTTP Response ，对有 HTTP 中间非业务相关的设备来说，肯定是不友好的。

当然，很多系统没有大到拥有非业务相关的 中间 HTTP 设备。

所以对于这种系统，这是一种传统约定的偷懒行为，能 work ，但并不是什么好的设计。
这样的系统一旦扩展，需要添加业务不相关的 网关、缓存之类的设施之后，就会因为 API 设计的偷懒 而 要复出 重构的代价。

@Balthild

2. “用 PUT 或者 PATCH ” 当然和 “用 GET / POST ” 有本质的区别。

我肯定你只是一直在 blah blah blah 而没有看到过我前面说过的区别，区别在于：如果 PUT 或者 PATCH 失败了，你可以通过 HTTP STATUS 知道是资源不存在还是 API 调用有错误，但你只用 GET ／ POST 没法保证只需在 HTTP 层解析就知道是什么错误。

这个问题就好像你调用 int GetNumber() 这样的接口，如果返回 -1 你无法判断这是一个错误还是一个结果。
而现代的做法应该是类似于 Either<int, Error> GetNumber() .

你要说前者足够你的业务使用就算了，这没问题，你喜欢就好。
但非要指责抽象形式 Either<int, Error> 是死板，我只能说这是井底之蛙夏虫语冰。

3. 你倒是找一个 RESTful 做不出来的需求啊…… 抓文字游戏胜利了显得你很聪明？

“ PUT 一个 PATCH ” 这种说法让我发现回答你真是浪费时间，原来你连 RESTful 除了 PUT 之外还有 PATCH 都不清楚啊……

你觉得你还好意思跟我 讨论 RESTful 不行么？
自己去看吧，不用谢： https://tools.ietf.org/html/rfc5789

移动一个资源怎么用 PATCH ？简单:

PATCH .../HugeResource/1234567

{"oldPath": "../old/path/to/resource",
"newPath": "../new/path/to/resource"
}

不改变资源的物理位置，改变资源挂载位置，这是不是移动？嗯？

我都说了，只要你的业务可以设计成这样，就可以支持这样的操作，跟 RESTful 一点关系都没有
难道你只会用 cp 和 rm 不知道有 mount ？

@Balthild
你非要认为移动是特殊的动作。业务许可的话，难道就不能一个 Put 或者 Patch 请求解决么。把资源的位置视作一种扩展属性，这样不 RESTful 么？这根本不是什么本质上的缺陷。

我已经解释过了，有很多种抽象的方式和角度，但是 RESTful 大多可以满足。要做成事务还是两个请求还是一个请求，看具体需要。视乎系统怎么设计有什么需求。

你非要用你死板而缺乏想象力的方式来想象我使用 RESTful 的方式，我只能认为这是不断给我打你脸的机会。

@Balthild 说你不够资格并不是否定你评论的权利，只是想让大家以及你确定，是否在浪费时间。然而现在看来你确实是浪费时间。

1 你当然可以设计这样的规范，并且或许已经有这样的实现。但是并没有普及。我已强调过了，有现成的规范你不妨介绍给大家。
但是，“动作”本身就是业务的一部分。如果真的有这么一份规范，并且每个动作都形成具体的规定，我预感它要遵守的规范也好习惯也好不比 HTTP 动作简单。
再者，”动作“本身是不是一定要有原子性语义，这还是业务决定的。所以你的提议听起来感觉就很临时。

2. CRUD 是普遍存在的需要。把 CUD 三类请求放在了 POST 里面不是不可以，但这样你又必须把动作写在业务代码里面，既然这样，为什么不直接用 HTTP 语义？
再往深了说，非纯函数式编程的语言里面，哪个语言没有这个过程：定义符号（变量）-> 读取／修改符号（变量） -> 符号（变量）离开作用域。 POST GET PUT DELETE 恰好就是这个过程的对应。换句话说，遵守 RESTful 规范，你的系统潜在地拥有了一个描述符号演算系统的能力，这比你什么鬼“动作”有根据多了。

3. 脱离业务实现谈效率是扯淡。

“自身水平沒有欲批評的對象高，便無資格作批評”

不解释。

@Balthild

说你只懂拆台不懂具体建议，是因为 RESTful 有现成的例子所以你可以发出数不尽的批评而不需要意识到自己的不足。

我之前已经说过了，只要你想清楚了，你可以再做一份自认为比 RESTful 更好的规范。如果没有， RESTful 本身是一套很好的规范。从上下文来看，你批评 RESTful 的地方恰恰都是你没有想清楚的地方。

没错，我是想转移话题——你还没够资格批评 RESTful 哪里不好，或者没有到点上。

@Balthild

1. 请问新浪微博 API Twitter API Facebook API 这些，前后端分离在哪里？他们是不是 RESTful ？
再强调一遍。前端不行是前端的事；前后端分离是前后端分离的事；前后端分离之后如果有事务，即使不用 RESTful 前端一样要有事务的概念。 RESTful 能解决这些问题，但并不是只解决这些问题，你拿这些来说 RESTful 不行是因为 你不行。

2. 可是使用 RESTful 的人可以有无数种抽象出资源的方式。显然你不行，所以你用不了 RESTful 。

3. 删除 GB 级别的操作又怎么样。你写代码的时候，知道有异步操作，知道可以用 Promise 或者 Task ，怎么在设计 RESTful API 的时候就不懂设计 Promise 或者 Task 资源？ 这是你蠢还是 RESTful 蠢？