 |
 |
On Sun, Dec 1, 2013 at 5:57 PM, Barnes, Hugh <[log in to unmask]>wrote: > +1 to all of Richard's points here. Making something easier for you to > develop is no justification for making it harder to consume or deviating > from well supported standards. > I'm not suggesting deviating from well supported standards, I'm suggesting choosing a different approach within the well supported standard that makes it easier for both consumer and producer. > > [Robert] > > You can't > > just put a file in the file system, unlike with separate URIs for > > distinct representations where it just works, instead you need server > > side processing. > > If we introduce languages into the negotiation, this won't scale. > Sure, there's situations where the number of variants is so large that including them all would be a nuisance. The number of times this actually happens is (in my experience at least) vanishingly small. Again, I'm not suggesting an arbitrary API, I'm saying that there's easier ways to accomplish the 99% of cases than conneg. > [Robert] > > This also makes it much harder to cache the > > responses, as the cache needs to determine whether or not the > > representation has changed -- the cache also needs to parse the > > headers rather than just comparing URI and content. > > Don't know caches intimately, but I don't see why that's algorithmically > difficult. Just look at the Content-type of the response. Is it harder for > caches to examine headers than content or URI? (That's an earnest, perhaps > naïve, question.) > > If we are talking about caching on the client here (not caching proxies), > I would think in most cases requests are issued with the same Accept-* > headers, so caching will work as expected anyway. > I think Joe already discussed this one, but there's an outstanding conneg caching bug in firefox and it took even Squid a long time to implement the content negotiation aware caching. Also note, "much harder" not "impossible" :) No Conneg: * Check if we have the URI. Done. O(1) as it's a hash. Conneg: * Check if we have the URI. Parse the Accept headers from the request. Check if they match the cached content and don't contain wildcards. O(quite a lot more than 1) > [Robert] > > Link headers > > can be added with a simple apache configuration rule, and as they're > > static are easy to cache. So the server side is easy, and the client > side is trivial. > > Hadn't heard of these. (They are on Wikipedia so they must be real.) What > do they offer over HTML <link> elements populated from the Dublin Core > Element Set? > Nothing :) They're <link> elements in a header so you can use them in non HTML representations. My whatever it's worth . great topic, though, thanks Robert :) > Welcome :) Rob