REST and URI caching

Question

As I understand it, using the hypertext-driven RESTful web service, the client should not know anything about the layout of the server URI, except for a couple of well-known entry points. This should allow the server to manage its own URI space and reduce communication with the client.

When a client for a service sends a successful request to create a new resource, the service responds with 201 CREATED and gives a URI to which the new resource can be accessed in the Location header field.

If the client is allowed to store this URI to provide direct access to the resource in the future, and if so, for how long? If the URIs are cached by the client, this seems to create a situation in which every time the server changes its URI layout, it needs to make sure that the persistent redirect will be served when accessing the old URIs. Otherwise, the client breaks down. For several years this forwarding system could get out of hand.

This situation did not seem to give the server much more control over its URI space than the REST-RPC hybrid approach using URI patterns.

There is a lot of information about view caching, but what about URI caching in hypertext-driven RESTful systems?

Answer 1

Remember, Tim Berners-Lee said, "cool URLs don't change." After the server issues the URI to the client, the server job should now support the URI in the future (for example) by sending a "Moved-Constant" response in case of a change in the URI and someone asks for the old one.

This is actually what prompts many to develop opaque URIs, for example, based on database identifiers or timestamps, instead of using some readable resource property in the URI. Everything that people understand, they will want to change.

Answer 2

Yes, the client should be allowed to store URIs. As long as he wants it. As Leakey said, a smart client can use the Moved-Permanent response to update their bookmarks.

If you think about it, we will have the best possible situation. You can change the URLs on the server, while at the same time preferring to support old clients as long as we choose, and intelligent clients can automatically automatically update themselves to new URLs.

How long you decide to continue to support these old URLs is actually a decision that must be made based on existing customers and the ease with which they can be supported.

For me, this is a huge improvement over versions with RPC-style interfaces.

Answer 3

I know this is an old question, but I think there is a subcomponent to the answers that I see here that have not been considered.

Remember that you are not retrieving a resource from the server, but you are getting a REPRESENTATION of the resource. The resource itself may have a change in the primary identifier or be remixed or something else, but the view that was returned to the client when the resource was created may (or cannot) be valid independently; it's all about the situation.

As an example, consider a moderated content loading system; the user may be able to upload content for review by moderators, which may ultimately lead to the content being presented to a wider audience / market. At boot, the server may respond with a URI that directs (say) "users / {userid} / uploaded / {contentid}" for this presentation of this content. At some point, the moderators may decide to promote the content on the "main page"; that the content view may be available in the URI "content / {contentid}"; which should not prevent the source loader from accessing their data on "users / {userid} / uploaded / {contentid}"; nothing says the need for constant redirection, and in fact there is a good reason for this to not be; if the user decides that he wants to delete the content, they should be able to perform DELETE on the content; probably much more preferable for users to do DELETE in content views from their “loaded” locations. However, if the conditions of the site indicate that the user’s rights to the downloaded content are canceled (not uncommon), it may make sense to force the moderation promotion process to effectively remove the content from the user's own area, causing a “constant move”.

It really depends entirely on the specific situation; the validity of the cached URI depends entirely on server policies. At the very least, I think that a request for an invalid URI (which might have been previously valid) should trigger a response (corresponding to HATEOAS) that could allow the client to "reopen" the resource (view) they were looking for; at least a link to the entry point.

Answer 4

Since one of the principles of REST is that resources are addressable, it seems quite acceptable for a client to track the address (URI) for a given resource. Resource URIs should be one of the "well-known entry points" that you talked about.