21 ms·

I appreciate the thought that's gone into this, but I don't know how robust this solution is, and, worse than that, it's a solution in search of a problem. It n

by scarmig 13y ago

I appreciate the thought that's gone into this, but I don't know how robust this solution is, and, worse than that, it's a solution in search of a problem. It needlessly complicates things while providing no clear value. How, for instance, do proxies interact with these headers? I think that they should still properly serve from cache when possible, but I wouldn't bet the farm on it. Have you investigated this? And how's client support for this? Quick Googling reveals someone complaining about 206 responses not being cached by several clients, including Chrome and Firefox. On top of that, putting range information in query parameters lends itself much better to HATEOAS. I get a URL with some parameters, I know that given a next relation all I need to do is navigate to that URL to get the next page of results. With yours, all I've got is you saying "these headers mean this." Thoughts?

begriffs 13y ago
Yeah, it's most definitely a solution in search of a problem -- although in this case the solution is an RFC from 1999. I wish we could take HTTP at its word, but maybe that's too much to ask in this wild world of recalcitrant proxies and buggy browsers. Like you pointed out, this header business doesn't let you do anything you theoretically couldn't do with query params, but the headers feel more in the spirit of HTTP. Like we already do this for downloading parts of big files, and why do we do things a different way for downloading parts of big lists? Parsimony and all that. As far as violating HATEOAS, I feel like headers are a first class citizen of HTTP state. Because browsers have historically been such horrible user agents they have conditioned us to forget that headers are as much a part of requests as urls, ports, and protocols.The only janky thing is my introduction of the extension relation type "items." http://tools.ietf.org/search/rfc5988#section-4.2 http://tools.ietf.org/search/rfc5988#section-4.2

by scarmig 13y ago

begriffs 13y ago

Yeah, it's most definitely a solution in search of a problem -- although in this case the solution is an RFC from 1999. I wish we could take HTTP at its word, but maybe that's too much to ask in this wild world of recalcitrant proxies and buggy browsers. Like you pointed out, this header business doesn't let you do anything you theoretically couldn't do with query params, but the headers feel more in the spirit of HTTP. Like we already do this for downloading parts of big files, and why do we do things a different way for downloading parts of big lists? Parsimony and all that. As far as violating HATEOAS, I feel like headers are a first class citizen of HTTP state. Because browsers have historically been such horrible user agents they have conditioned us to forget that headers are as much a part of requests as urls, ports, and protocols.The only janky thing is my introduction of the extension relation type "items." http://tools.ietf.org/search/rfc5988#section-4.2 http://tools.ietf.org/search/rfc5988#section-4.2