据我了解，使用hypertext-driven RESTful Web 服务，客户端不应该知道任何关于服务器URI 布局的信息，除了几个众所周知的入口点。这应该是为了使服务器能够控制自己的 URI 空间并减少与客户端的耦合。
当服务的客户端成功发送创建新资源的请求时，服务会响应 201 CREATED 并在 Location 标头字段中提供可以访问新资源的 URI。
是否应该允许客户端存储此 URI 以便将来能够直接访问资源？如果可以，持续多长时间？如果 URI 被客户端缓存，这似乎设置了一种情况，即每次服务器更改其 URI 布局时，它需要确保在访问旧 URI 时提供永久重定向。否则客户端中断。几年后，这种重定向系统可能会失控。
与使用 URI 模板的 REST-RPC 混合方法相比，这种情况似乎不会给服务器更多对其 URI 空间的控制。
有很多关于缓存表示的信息，但是在超文本驱动的 RESTful 系统中缓存 URI 呢？
【问题讨论】：
由于 REST 的原则之一是资源是可寻址的，因此客户端跟踪给定资源的地址 (URI) 似乎完全可以接受。资源 URI 应该是您提到的“众所周知的入口点”之一。
【讨论】：
请记住，正如 Tim Berners-Lee 所说，“酷 URL 不会改变”。一旦服务器将 URI 分发给客户端，现在服务器的工作就是通过（例如）发送 Moved-Permanently 响应来保持 URI 在未来正常工作，以防 URI 发生更改并且有人请求旧的响应。
这实际上是鼓励许多人设计不透明 URI 的原因，例如基于数据库 ID 或时间戳，而不是在 URI 中使用资源的某些人类可读属性。任何人们理解的东西，他们都会想要改变。
【讨论】：
是的，应该允许客户端存储 URI。只要它愿意。正如 Licky 提到的，智能客户端可以使用 Moved-Permanently 响应来更新其书签。
如果您考虑一下，我们的情况可能是最好的。您可以更改服务器上的 url，同时选择仍然支持旧客户端，只要我们选择，智能客户端可以有效地自动更新到新的 url。
您选择继续支持这些旧网址多长时间确实是一个需要根据现有客户以及它们可以维护的难易程度做出的决定。
对我来说，这是对 RPC 样式接口的版本控制问题的巨大改进。
【讨论】：
我知道这是一个老问题，但我认为我在这里看到的答案有一个子组件尚未解决。
请记住，您不是从服务器检索资源，而是检索资源的 REPRESENTATION。资源本身可能会更改其主要标识符，或重新归位，或其他任何事情，但在资源创建时返回给客户端的表示可能（或可能不）独立有效；这都是情况的问题。
例如，考虑一个有节制的内容上传系统；用户可能有能力上传内容供版主考虑，这可能最终导致内容暴露给更广泛的受众/市场。在初始上传时，服务器可能会使用指向（比如说）“users/{userid}/uploaded/{contentid}”的 URI 来响应该内容的表示。在某些时候，版主可能会决定将内容推广到“首页”；然后可以在“content/{contentid}”的 URI 处获得该内容的表示；这不应阻止原始上传者在“users/{userid}/uploaded/{contentid}”访问他们的数据；没有人说需要永久重定向，事实上，有充分的理由不需要；如果用户决定要删除内容，他们应该能够对内容执行 DELETE；让用户从他们自己的“上传”位置对内容表示进行删除可能是非常优惠的。但是，如果网站的条款表明用户对上传内容的权利被撤销（并不少见），那么让审核促进过程有效地将内容从用户自己的区域中删除可能是有意义的，从而导致“永久迁移”。
这完全取决于具体情况；缓存 URI 的有效性完全取决于服务器的策略。至少，我认为对无效 URI（以前可能是有效的）的请求应该会导致响应（与 HATEOAS 一致），该响应可以允许客户端“重新发现”他们正在寻找的资源（表示） ;至少，一个指向入口点的链接。
【讨论】：