Note that there are some explanatory texts on larger screens.

plurals
  1. POI'm confused about HTTP caching
    primarykey
    data
    text
    <p>I've been thinking about batch reads and writes in a RESTful environment, and I think I've come to the realization that I have broader questions about HTTP caching. (Below I use commas (",") to delimit multiple record IDs, but that detail is not particular to the discussion.)</p> <p>I started with this problem:</p> <h2>1. Single <code>GET</code> invalidated by batch update</h2> <pre><code>GET /farms/123 # get info about Old MacDonald's Farm PUT /farms/123,234,345 # update info on Old MacDonald's Farm and some others GET /farms/123 </code></pre> <p>How does a caching server in between the client and the Farms server know to invalidate its cache of <code>/farms/123</code> when it sees the <code>PUT</code>?</p> <p>Then I realized this was also a problem:</p> <h2>2. Batch <code>GET</code> invalidated by single (or batch) update</h2> <pre><code>GET /farms/123,234,345 # get info about a few farms PUT /farms/123 # update Old MacDonald's Farm GET /farms/123,234,345 </code></pre> <p>How does the cache know to invalidate the multiple-farm <code>GET</code> when it sees the PUT go by?</p> <p>So I figured that the problem was really just with batch operations. Then I realized that any relationship could cause a similar problem. Let's say a farm has zero or one owners, and an owner can have zero or one farms.</p> <h2>3. Single <code>GET</code> invalidated by update to a related record</h2> <pre><code>GET /farms/123 # get info about Old MacDonald's Farm PUT /farmers/987 # Old MacDonald sells his farm and buys another one GET /farms/123 </code></pre> <p>How does the cache know to invalidate the single GET when it sees the PUT go by?</p> <p>Even if you change the models to be more RESTful, using relationship models, you get the same problem:</p> <pre><code>GET /farms/123 # get info about Old MacDonald's Farm DELETE /farm_ownerships/456 # Old MacDonald sells his farm... POST /farm_ownerships # and buys another one GET /farms/123 </code></pre> <p>In both versions of #3, the first GET should return something like (in JSON):</p> <pre><code>farm: { id: 123, name: "Shady Acres", size: "60 acres", farmer_id: 987 } </code></pre> <p>And the second GET should return something like:</p> <pre><code>farm: { id: 123, name: "Shady Acres", size: "60 acres", farmer_id: null } </code></pre> <p>But it can't! Not even if you use <code>ETag</code>s appropriately. You can't expect the caching server to inspect the contents for <code>ETag</code>s -- the contents could be encrypted. And you can't expect the server to notify the caches that records should be invalidated -- caches don't register themselves with servers.</p> <p>So are there headers I'm missing? Things that indicate a cache should do a <code>HEAD</code> before any <code>GET</code>s for certain resources? I suppose I could live with double-requests for every resource if I can tell the caches which resources are likely to be updated frequently.</p> <p>And what about the problem of one cache receiving the <code>PUT</code> and knowing to invalidate its cache and another not seeing it?</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload