据我了解，使用超文本驱动的RESTful Web 服务，客户端不应该知道任何关于服务器 URI 布局的信息，除了几个众所周知的入口点。这应该使服务器能够控制自己的 URI 空间并减少与客户端的耦合。
当服务的客户端成功发送创建新资源的请求时，服务会响应 201 CREATED 并在 Location 标头字段中提供可以访问新资源的 URI。
是否应该允许客户端存储此 URI 以在将来启用对资源的直接访问，如果可以，持续多长时间？如果 URI 被客户端缓存，这似乎设置了一种情况，即每次服务器更改其 URI 布局时，它需要确保在访问旧 URI 时提供永久重定向。否则客户端中断。几年后，这种重定向系统可能会失控。
与使用 URI 模板的 REST-RPC 混合方法相比，这种情况似乎不会给服务器更多对其 URI 空间的控制。
有很多关于缓存表示的信息，但是在超文本驱动的 RESTful 系统中缓存 URI 呢？
请记住，正如 Tim Berners-Lee 所说，“酷 URL 不会改变”。一旦服务器将 URI 分发给客户端，现在服务器的工作就是通过（例如）发送 Moved-Permanently 响应来保持 URI 在未来正常工作，以防 URI 更改并且有人请求旧的响应。
这实际上是鼓励许多人设计不透明 URI 的原因，例如基于数据库 ID 或时间戳，而不是在 URI 中使用资源的某些人类可读属性。人们理解的任何事情，他们都会想要改变。
是的，应该允许客户端存储 URI。只要它愿意。正如 Licky 提到的，智能客户端可以使用 Moved-Permanently 响应来更新其书签。
如果你考虑一下，我们有最好的情况。您可以更改服务器上的 url，同时选择仍然支持旧客户端，只要我们选择，智能客户端可以有效地自动更新到新的 url。
您选择继续支持这些旧 url 多长时间确实是一个需要根据现有客户端以及它们可以维护的难易程度做出的决定。
对我来说，这是对 RPC 样式接口的版本控制问题的巨大改进。
I know this is an old question, but I think there's a subcomponent to the answers that I see here that hasn't been addressed.
Remember that you're not retrieving the resource from the server, but you're retrieving a REPRESENTATION of a resource. The resource itself may have its primary identifier change, or be rehomed, or whatever, but the representation that was returned to the client on resource creation may (or may not be) valid independently; it's all a matter of situation.
As an example, consider a moderated content upload system; a user may have the ability to upload content for consideration by the moderators that may eventually cause the content to be exposed to a wider audience / market. On initial upload, the server may respond with a URI that directs to (say) "users/{userid}/uploaded/{contentid}" for that representation of that content. At some point, the moderators may decide to promote the content to a "front page"; that representation of the content may then be available at the URI of "content/{contentid}"; that should not prevent the original uploader from accessing their data at "users/{userid}/uploaded/{contentid}"; nothing says that there needs to be a permanent redirect, and in fact, there's good reason for there not to be; if the user decides they want to remove the content, they should be able to perform a DELETE on the content; it's probably much preferential to have users doing DELETEs to the content representations from their own "uploaded" locations. However, if the terms of the site indicate that user rights to content uploaded are revoked (not uncommon) it might make sense to have the moderation promotion process effectively remove the content from the user's own area, causing a "permanent move".
It's really entirely dependent upon the specific situation; the validity of a cached URI is completely dependent upon the server's policies. At the least, I'd think that a request to an invalid URI (that may have previously been valid) should cause a response (consistent with HATEOAS) that can allow the client to "rediscover" the resource (representation) they were looking for; at the very least, a link to the entry-point.
由于 REST 的原则之一是资源是可寻址的，因此客户端跟踪给定资源的地址 (URI) 似乎完全可以接受。资源 URI 应该是您提到的“众所周知的入口点”之一。