I didn't either - in path params seems like an interesting way to address issues that can come up when devising RESTful URL schemes (rather than relying on query params only).
For fucks sake, there is no such thing as a RESTful URL scheme. 'Pretty' URLs are a major anti-pattern -- they not only don't make you any more RESTful, they actively undermine HATEOAS, which is the true signifier of RESTfulness.
Actual REST treats URL strings (including query parameters) as being completely opaque implementation details. The server is supposed to respond with URLs in the hypertext -- you're never supposed to be formatting them yourself client-side using out of band knowledge. Query parameters are no exception to that: if you want the client to pass them, give the client a form in the response.
If you're expecting a client to munge together "path components" based on foreknowledge of your data model, you're doing it wrong.
Any chance you have articles to back this up? Not that I doubt you, but I've never really understood or looked into all this REST business and if I'm ever going to do so, I'd like to learn what being RESTful really means --- and not just jumping on what sounds like a bandwagon for 'Pretty URLs' as you mentioned. :)
How are you supposed to represent collections, if every link must be provided by the server? I've seen REST examples where you give some results and a link to the next page of results. That's impractical if you have a million pages.
If your collection is truly random access (array, search results, relational sets) then use a form that takes the 'foreign key' as input. Then there's one URL and standard query parameters.
In pretty much all other cases a collection would have data/metadata in the response that far outweighs the links. And given that it's perfectly fine for the links to be completely opaque, there's no reason for them to be very long.
The real problem with pagination is that all but a few brave souls completely fuck up the implementation of it. This is the worst possible way to paginate something, but just about every webapp ever written does it like this:
SELECT * FROM posts ORDER BY date DESC LIMIT x OFFSET n*x
The locations of items on pages change constantly as new items are created and destroyed! You page through the history (usually via links with the worst possible names: prev & next), and the items shift around as you move around. It's OK that the page with the most recent items changes as new ones are created, but having the archives be a pushdown stack is just idiotic.
It would be terrific if people used meaningful pagination instead of arbitrary offsets: posts by year/month/week/day/hour/minute/second/etc. is far better than "Page N" -- you don't even need to give me any options, just use older/newer links that point to the level of granularity that would give an appropriate number of results.
