服务器物理架构,REST架构风格是否需要物理上独立的客户端和服务器？

在进程中使用REST原则和HTTP语义肯定是有意义的，但可能只有当您的应用程序最终也是与HTTP通信的客户端或服务器时。

困难的部分是尊重HTTP的分层约束，因为它很容易在该层的另一个sie上调用该单例，因为它只是一个函数调用。

然而，一个好处是，您实际上可以将图层从一个地方移动到另一个地方。可能很难完全实现这一点，但我认为这是可行的，尽管我猜测它从未被完成。

在我自己的想法实验中，HTTP的所有好处都发挥作用，仅仅是memcached或进程内缓存无法处理它的方式。以缓存验证或条件放置为例。想象一下，能够通过HTTP请求的表达来进行函数调用：

从这个服务中检索这个东西，但只有当它的ETag不是“A”或“B”或W /“C”时，因为那些是我现在拥有的那个

要么

将此存储在此处，但仅当ETag W /“DEF”仍然有效时，因为这是我刚刚完成GET时使用的标记。

和

我想搜索这样的小部件，并将结果最好作为IAtomCollection，但我将改为使用List(Accept)。我最后一次问这个问题时，我得到了一个“foo”(如果没有匹配)的ETag，所以如果它没有改变我就不需要它，但是如果你不介意的话，我想要验证我的缓存与源服务器的有效性(Cache-Control：must-revalidate)。哦，顺便说一句，这是我的证书(授权)。

这些问题在HTTP中很容易实现，我们都知道如何伪造这些复杂的查询。

HTTP响应也是如此：

嗨，我找到了你的IAtomCollection，我确实用原始服务器验证了它。你拥有的东西不再有效，所以这里有一个新的。它有“酒吧”的ETag，你可以考虑新鲜两分钟而不与我重新验证，但如果我下次再问你，你可以将新鲜期延长一分钟。当然，响应会根据您的凭据(不用说，对吗？)和您的偏好而有所不同。

再次，普通的旧HTTP。想象一下，能够进行那些聪明的方法调用！

至于HATEOAS，将一些想法用于封装标识符也可以使这种约束成为可能。但是我的思想实验并没有走向这个方向......