@wizardoz 说得太好了。要的就是优雅。

那些说 RESTful 是 风格而不是规范的同志们，扯这个没用。
你看看各大平台下的各种 RESTful 相关的库，你就知道什么是风格什么是规范了。
遵守这个风格也好，规范也好，就提供一种使用开源代码的机会。
不遵守也不是不行，自己掌握细节，然后实际上是把 RESTful 的规范用另外一种形式实践一遍。

@magict4

在一个 openstack 相关的业务里面，我用 RESTful 实现过对 AD （ ActiveDirectory ）相关的接口 WEB 封装。
里面也是经常有对各种简单的、原子的 对各种 AD 条目的操作的 组合所形成的事务。
提交事务方法只有一种：
```
POST .../Transaction
```
然后在请求体里面用 JSON 描述这个事务的各种操作和参数，例如：

```
{
[
{"method": "POST", "resource": "/someResources", "args": {...} },
{"method": "DELETE", "resource": "/someResource/1234"},
]
}
```
实际上就是把一连串的 RESTful API 调用转化成一个 JSON 对象来描述要执行的事务。

所以你说“同样的一件事情，因为实现不同，对应的接口变了” 实际上不存在～ ：）

@murmur

"比如 /api/removeItem 和 /api/item 发 del 有什么区别么？"

见 #15

@magict4

我说的 Messages 是类似于论坛消息之类的业务 Message ， Email 概念的泛化、抽象化。
你当然可以不用 Restful 来实现，而且我本人也不建议。
你要我举个例子，那我就免为其难了。

事实上，我认为，操作系统的全部 系统调用，都可以用 RESTful API 来对应表示。
不习惯的人可能会觉得别扭，但是是可行的、科学的、经得起考验的。

@gamexg

如果不需要解析错误信息呢？ RESTful 能够照顾到两种需求。
如果直接返回 200 做不到这一点。

@magict4

如果将 Email 视作 Resource ，或者更广泛地考虑，用 RESTful 来描述 IM 消息：
向某人发送消息，应该是在 其消息队列中 POST 一个新资源， 用
```
POST /{SomeBody}/messages/
```
存档某消息，其实也就是同样的意思

移到文件夹 X 这里面略坑，因为包括两个步骤： 1. 在新位置复制一个 2. 在旧位置删除
看需要是否做成事务式的：
如果是事务式的，应该是事务队列增加一个资源

如果不是事务式的，那么分别执行 POST 和 DELETE

@cloudyplain
URL 名称叫做 Universal Resource Location ，本来只是用来表明资源的位置。
而加上动作前缀，也不是不可以，但这种方式偏离了表示资源位置的本意，耦合了其他语义。

例如， getResource 返回 404 ，那么可以有两种方式理解：
1. 不看动词，表明该资源不存在
2. 看动词，表明 1 ）不存在这种资源，或者 2 ）不存在对这种资源的操作，或者 3 ）资源存在但不支持这种操作

@wingoo

想向你补充一句：
按照 RESTful 的设计来做不叫迷恋权威。
而是不必自己另外发明一套轮子。

@xgfan 对于资源增删查改不够的话，请问要加上什么操作？能不能举个例子？

@wingoo 你说的 GET .../getResource1 是只把 resourceId 作为后缀填到 URL 里面去吗？那这跟 RESTful 有什么区别？
RESTful 不能统一处理吗？能否统一处理是后端架构的问题，跟 RESTful 无关。

@laxenade RESTful 是 HTTP 之上的概念， 404 是 HTTP 的概念，不同层。如果 HTTP 语义都不遵守，确实没啥好说的。

@firefox12

更高级的玩法是，既然你用的是固定密钥，那我只需要在 可执行映像中找到你的密钥就可以了。
除非 LZ 能保证，所有分发的软件都是 code sign 保护过的。

@firefox12 但实际情况是，中间人不仅仅是监听人，它也可以主动发起通讯啊。
所以这种情况下，除非设计协议的时候有考虑 IV 部分，不然中间人可以一直用 同一个 IV 来玩啊

@firefox12

IV 在实践中的确是不固定的，但通讯双方也需要明文交换 IV 。
所以你总是有办法让 IV 变成固定的。

@damean 来个实例验证吧。

AES256 CFB

明文：
Veni, vidi, vici
密钥：
ThePhantomOfTheOperaIsThere
IV ：
8c 8a 88 6c 24 e7 18 a1 91 7c 20 c4 f8 3e d2 5c
结果：
07 22 ff c3 .....

其他不变，明文换成：
Very good
结果
07 22 e3 cb ....

注意到重复的 07 22 了吗？

开头的这一部分，是绝对可以分析的。
如果恰巧知道报文的前面几字节是例如报文长度这样的信息，是有可能逐步攻破的。

@damean

给定密钥， IV ，和同一种模式， AES 怎么可能加密出不一样的密文？
你让解密方怎么解？

@firefox12 如果你说的是 AES 针对选择文本攻击的抵抗能力，这个我是理解的。

现在我们假设 LZ 的软件只采用一种特定模式的 AES 加密，并且已经分发到了足够多的网络节点上，然后我们在通讯旁路截取数据。

我们分析这些截取数据可以找到什么规律？
如果 LZ 仅仅做了 AES 加密的话，基本上我们可以分析出节点通讯的模式。
譬如是否有类似 Hello 报文，如何响应，
然后我们可以用重放这些报文，试图更改其中一些内容来验证一下对报文内容的猜测。

你还觉得这种方式不会泄密么？

SSL 通讯加密，可以在发起链接时通讯双方协商密钥，且保证未获许可的第三方试图攻破密钥是计算上不可能的。

你说的 AES 自行对通讯保文加密通讯，如果没有理解错的话，应该是指通讯双方事先已经知道共享的通讯密钥。在多次通讯中，这个密钥除非同时改变，否则双方无法通讯。
一般来说，这样的通讯方式会有以下问题：
1. 无法知道中间是否有第三者已经攻破密钥并截获通讯双方的内容，发起中间人攻击。
2. 更换密钥代价大，必须借助其他安全的信道更新密钥（例如通讯双方同时更新软件）
3. 多次使用同一密钥会使该密钥被攻破的可能性大大增加，尤其是通讯协议是有模式的，可以通过字典攻击倒推出密钥原文。

@dou4cc 你的缓存回收是纯内存操作？这个缓存回收是在异步操作里面完成？为什么要这样做？

@doucc

你期望的结果，跟你认为实际会发生的结果，在我认为的实际里面，实际上都有可能发生。
当然，一个异步结果很大可能总是会比下一个同步结果来得慢，但也并不是完全不可能得到相反的快慢结果。

所以你实际情景中遇到的问题是什么，请不要用自己的抽象来说明了，请直接一点吧。

要求进一步详细信息: 能不能添加一点代码示例来表达情况？