Re: Atom and prev links

Actually we have a pretty simple reason for this caching.

If we were to hide the prev that uri would have to be non-cachable. If we
put it there (we are forward only) then every valid uri we have is
infinitely cachable. By predefining the next only our non-existant uri is
non-cachable.

Though keeping the last existing one as non-cachable could also solve this
and maybe its a better overall way.

Cheers,

Greg

On Fri, Jun 28, 2013 at 1:47 PM, Markus Lanthaler
<[email protected]>wrote:

> **
>
>
> On Friday, June 28, 2013 12:16 PM, Greg Young wrote:
> > 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).
>
> Why don't you just hide the next/prev link till the next/prev resource
> really exists? If really necessary, the client can keep polling the last
> resource it encountered till the next/prev link becomes available. This
> also
> means that you can decide how to construct the URL of the new element as
> soon as it is created instead of relying on, e.g., an autoincrement.
>
> Did I miss something?
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>  
>



-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.