4

Let's say you've got a fully hypermedia driven API. Consumers have to navigate three reources, via following hypermedia, until they can get to the resource they want. Is there any reason a client could not cache these steps temporarily and go directly to the resource they want?

I know the goal of REST is to decouple clients and servers, but if you've got 5 web requests going on behind the scenes the user experience could be poor waiting for all this to happen.

The worst case I can think of is that a cached URL gets changed. And so the client will just start from the entrypoint again and cache the steps.

user2668128
  • 39,482
  • 8
  • 27
  • 34

1 Answers1

0

Caching on the client side is going to be very important for a lot of well performing Hypermedia clients. Here is some more specific guidance straight from Fielding's dissertation:

The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions. The trade-off, however, is that a cache can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent directly to the server.

The are trade offs but event a short time frame for caching will greatly improve performance. Ideally the Hypermedia API will provide caching guidance. This could be done in the same manner that HTML caching works with the browser and Expires and Cache-Control headers.

Also if the resource has moved then the API should inform you with the proper 301 Moved Permanently response.

kampsj
  • 3,139
  • 5
  • 34
  • 56