

AngularJS Paginated Resource - begriffs
https://github.com/begriffs/angular-paginated-resource

======
scarmig
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
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)

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

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

------
VexXtreme
> _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/>

------
nness
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.

~~~
begriffs
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.

