AngularJS Paginated Resource | Hacker News Reader

AngularJS Paginated Resource

github.com

14 pointsbegriffs8 comments

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?

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

A submission about pagination framed in a condescending tone? Lol.

Yeah I know, it's silly. But on HN the titles have to be over-the-top to get any votes. :)

>Give me everything! Nope too much, bro.

Brace yourself for a shitstorm. There was a guy yesterday who got attacked and nearly had his project forked under a different name for naming it "bro", which is obviously offensive to women and minorities. You insensitive jackass.

<popcorn.gif/>

Two things:

1. Isn't the Content-Range header for partial files (not sets of files). Since the spec seems to define it in terms of bytes, not arbitrary items.

2. I'd imagine you couldn't bookmark or share URL's using this method.

As scarmig pointed it, the spec allows custom range units. Downloading pieces of a big file seems to be to be essentially the same problem as downloading parts of a long list of items.

Also, I'm imagining this header approach more for API calls than for bookmarkable user-facing pages. This way the data that comes back from the server can be a clean array of results without metadata. Feels like metadata is what HTTP headers are for.

The RFC allows you to define an arbitrary unit for range. I agree that the submitter's use here is higher level than the range header is typically used for, but that's not the primary issue here.

Reply on news.ycombinator.com