Re: Atom and prev links

On Fri, Jun 28, 2013 at 12:16 PM, Greg Young <[email protected]>wrote:

> **
>
>
> We have a mature atom implementation for distribution of event streams
> and as always the devil is in the details...
>
> The issue revolves around prev links. At some point on an atom feed
> you will hit the current item, prev will point to the next item that
> does not yet exist. Most implementations I can find 404 this uri and
> the client has the logic to keep polling the 404. This seems off to
> me, I would expect this to be a 204. Then if I change my uri structure
> it becomes a 404, otherwise it would seem that if I change my uri
> structure all prev uris would need to redirect to the new ones (which
> would be a rather large undertaking).
>
> I couldn't find any details on this in relevant specs, has anyone seen
> this?
>
> Greg, I'd just like to explain how we do more or less the same thing.  We
also use the prev link of the "first page" of a feed to link to the page
containing the items that "will be".  We find that it's an extremely
resilient way of dissipating information about things that fit in atom
feeds, and a relatively efficient system too.

Infinitely cacheable resources are nice, but instead of 404, or 204 and so
on, we expose an empty feed document, with a next link but no prev link.
 When things happen, the page (when refreshed) contains one or more
entries, and becomes cacheable.

Our "head" document is very small; contains no real data so it's easy to
generate; supports cache validation, and if it's incorrectly cached as
fresh by an intermediary or a caching client, it only impedes the ability
of clients to advance to the "newer" entries.  Eventually, they will
advance to the next state.

If I were to do this again, I might consider using 302 some other temporary
redirect, instead of the 404 or the empty feed; redirect back to the
current (infinitely cacheable) first page.  When a new item appears, the
302 would turn into the "new" first page" a 200 with new next/prev links,

I wonder if "Cache-Control" or "Retry-After" would be useful for 302
responses, to ask clients to back off under heavy load.
-- 
-mogsie-