REST 和 URI 缓存
据我了解，使用 超文本驱动 RESTful Web 服务，除了几个众所周知的入口点之外，客户端不应该知道有关服务器 URI 布局的任何信息。 这应该使服务器能够控制自己的 URI 空间并减少与客户端的耦合。
当服务的客户端成功发送创建新资源的请求时，服务会响应 201 CREATED 并在 Location 标头字段中给出可以访问新资源的 URI。
是否应该允许客户端存储此 URI，以便将来能够直接访问该资源？如果可以，可以保存多长时间？ 如果 URI 由客户端缓存，这似乎会造成这样一种情况：每次服务器更改其 URI 布局时，都需要确保在访问旧 URI 时提供永久重定向服务。 否则客户端就会崩溃。 几年后，这种重定向系统可能会失控。
与使用 URI 模板的 REST-RPC 混合方法相比，这种情况似乎不会让服务器对其 URI 空间有更多的控制。
有很多关于缓存表示的信息，但是在超文本驱动的 RESTful 系统中缓存 URI 又如何呢？
As I understand it, using a hypertext-driven RESTful Web service, a client is not supposed to know anything about server URI layout except for a couple of well-known entry points. This is supposed to enable the server to control its own URI space and reduce coupling with the client.
When a client for the service sends a successful request to create a new resource, the service responds 201 CREATED and gives the URI at which the new resource can be accessed in the Location header field.
Should a client be allowed to store this URI to enable direct access to the resource in the future and if so for how long? If URIs are cached by the client, this seems to be setting up a situation in which every time the server changes its URI layout, it will need to make sure a permanent redirect gets served when old URIs are accessed. Otherwise the client breaks. Over several years, this system of redirects could get out of hand.
This situation would not appear to have given the server much more control over its URI space than a REST-RPC hybrid approach using URI templates.
There's a lot of information available about caching representations, but what about caching URIs in hypertext-driven RESTful systems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
请记住，蒂姆·伯纳斯·李 (Tim Berners-Lee) 说过，“酷的 URL 不会改变”。 一旦服务器将 URI 分发给客户端，服务器现在的工作就是通过（例如）发送 Moved-Permanently 响应来保持 URI 将来正常工作，以防 URI 更改并且有人请求旧的 URI。
这实际上鼓励许多人设计不透明的 URI，例如基于数据库 ID 或时间戳，而不是使用 URI 中资源的某些人类可读属性。 人们理解的任何事情，他们都会想要改变。
Remember as Tim Berners-Lee said, "cool URLs don't change". Once the server hands out a URI to the client, it is now the server's job to keep the URI working in the future by (for instance) sending a Moved-Permanently response in case the URI changed and someone requests the old one.
This is actually what encourages many to design opaque URIs, such as based on database ids or timestamps, rather than using some human-readable property of the resource in the URI. Anything that people understand, they will want to change.
是的，应该允许客户端存储 URI。 只要它愿意。 正如 Licky 提到的，智能客户端可以使用 Moved-Permanently 响应来更新其书签。
如果你仔细想想，我们的情况是最好的。 您可以更改服务器上的 url，同时选择在我们选择的时间内仍然支持旧客户端，智能客户端可以有效地自动更新到新的 url。
您选择继续支持这些旧网址多久实际上是一个需要根据现有客户以及维护它们的难易程度做出的决定。
对我来说，这是对 RPC 风格接口的版本控制问题的巨大改进。
Yes the client should be allowed to store the URI. For as long as it wants. As Licky mentioned a smart client can use a Moved-Permanently response to update its bookmarks.
If you think about it, we have the best possible situation. You can change the urls on the server, whilst choosing to still support old clients for as long as we choose, and intelligent clients can effectively auto update themselves to the new urls.
How long you choose to continue to support those old urls is really a decision that needs to be made based on the existing clients and the ease with which they can be maintained.
For me this is a huge improvement over the versioning issues with RPC style interfaces.
我知道这是一个老问题，但我认为我在这里看到的答案中有一个子组件尚未得到解决。
请记住，您不是从服务器检索资源，而是检索资源的 REPRESENTATION。 资源本身可能会更改其主标识符，或者重新定位，或者其他什么，但是在资源创建时返回给客户端的表示可能（或可能不是）独立有效； 这完全是情况问题。
作为一个例子，考虑一个经过审核的内容上传系统； 用户可以上传内容供版主考虑，这最终可能导致内容暴露给更广泛的受众/市场。 在初始上传时，服务器可能会使用一个 URI 进行响应，该 URI 指向（例如）“users/{userid}/uploaded/{contentid}”以表示该内容。 在某些时候，版主可能会决定将内容提升到“首页”； 然后，该内容的表示可以在“content/{contentid}”的 URI 处获得； 这不应阻止原始上传者访问“users/{userid}/uploaded/{contentid}”处的数据； 没有人说需要有一个永久的重定向，事实上，有充分的理由不需要这样做； 如果用户决定要删除内容，他们应该能够对内容执行 DELETE； 让用户从自己的“上传”位置对内容表示进行删除可能会更有利。 然而，如果网站的条款表明用户对上传内容的权利被撤销（并不罕见），那么让审核升级流程有效地从用户自己的区域中删除内容，从而导致“永久移动”可能是有意义的。
这完全取决于具体情况； 缓存的 URI 的有效性完全取决于服务器的策略。 至少，我认为对无效 URI（以前可能有效）的请求应该会导致响应（与 HATEOAS 一致），从而允许客户端“重新发现”他们正在寻找的资源（表示） ; 至少，有一个指向入口点的链接。
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 应该是您提到的“众所周知的入口点”之一。
Since one of the principals of REST is that resources are addressable, it seems perfectly acceptable for a client to keep track of the address (URI) for a given resource. Resource URIs should be one of the "well known entry points" you referred to.