REST和URI缓存

Question

据我所知，使用REST风格的Web服务，客户端不应该知道关于服务器URI布局的任何信息，除了几个众所周知的入口点。这应该使服务器能够控制自己的URI空间并减少与客户端的耦合。

当服务的客户端发送成功的请求以创建新资源时，服务会响应201 CREATED，并在位置标题字段中提供可访问新资源的URI。

是否允许客户端存储此URI，以便将来可以直接访问资源，如果存在多长时间？如果客户端对URI进行缓存，这似乎设置了一种情况，即每次服务器更改其URI布局时，都需要确保在访问旧URI时获得永久重定向。否则，客户中断。几年来，这种重定向系统可能会失控。

与使用URI模板的REST-RPC混合方法相比，这种情况似乎没有赋予服务器对其URI空间的更多控制权。

关于缓存表示有很多可用的信息，但是在超文本驱动的RESTful系统中如何缓存URI？

Answer 1

请记住，蒂姆伯纳斯李说，“酷URL不会改变”。一旦服务器将URI发送给客户端，现在服务器的工作就是通过（例如）发送Moved-Permanently响应来防止URI在未来工作，以防URI发生变化并且有人请求旧的响应。

这实际上鼓励很多人设计不透明的URI，例如基于数据库ID或时间戳，而不是使用URI中资源的某些人类可读属性。任何人都明白，他们会想要改变。

Answer 2

由于REST的主要原因之一是资源是可寻址的，客户端跟踪给定资源的地址（URI）似乎是完全可以接受的。资源URI应该是您提到的“众所周知的入口点”之一。

Answer 3

是的，客户端应该被允许存储URI。只要它想要。正如Licky提到的，智能客户可以使用Moved-Permanently响应来更新其书签。

如果你仔细想想，我们有最好的情况。您可以更改服务器上的网址，同时选择仍旧支持旧客户端，并且智能客户端可以有效地将自己更新到新的网址。

您选择继续支持这些旧网址需要多长时间才是真正的决定，需要根据现有客户和他们可以轻松维护。

对我来说，这是对RPC样式接口版本问题的巨大改进。

Answer 4

我知道这是一个老问题，但我认为这里有一个子组件，我在这里看到的答案没有得到解决。

请记住，您没有从服务器检索资源，但是您正在检索资源的表示。资源本身可能会有其主要标识符更改，或重新注册等等，但是在创建资源时返回给客户端的表示可能（或可能不是）独立有效;这都是情况的问题。

作为一个例子，考虑一个适度的内容上传系统;用户可能有能力上传内容供审核人考虑，最终可能导致内容暴露给更广泛的受众/市场。在初始上传时，服务器可以用指向（比方说）用户/ {userid}/uploaded/{contentid}“的URI来响应该内容的表示。在某些时候，版主可能决定将内容推广到“首页”;那么内容的表示可以在“content/{contentid}”的URI处可用;这不应阻止原始上传者在“users/{userid}/uploaded/{contentid}”上访问其数据;没有什么表示需要永久性的重定向，事实上，没有理由存在;如果用户决定要删除内容，他们应该能够对内容执行DELETE操作;用户可以通过自己的“上传”位置对内容表示进行删除，这可能是非常优惠的。但是，如果网站的条款表明用户对上传内容的权利已被撤销（并不少见），那么让审核提升流程有效地从用户自己的区域移除内容可能是有意义的，从而导致“永久移动”。

这完全取决于具体情况;缓存的URI的有效性完全取决于服务器的策略。至少，我认为对无效URI的请求（可能以前是有效的）应该会导致响应（与HATEOAS一致），这可以允许客户“重新发现”他们正在寻找的资源（表示） ;至少是进入点的链接。