Comments on: REST design question #2: listing and discovering resources

By: Bo

Bo — Tue, 22 Feb 2005 23:14:29 +0000

No, ‘next-page’ is an ugly design in my opinion. Logically, the /airports is a resource that represents a collection of other resources. You should query this collection using query strings. GET /airports should, in my opinion, return information about the COLLECTION of airports eg the number of airports contained, the name of the first airport, the name of the last airport, etc. As for the general question of returning too many results for a query I don’t think it’s a problem. You don’t need paging because a computer doesn’t need to scroll through thousands of results. Another solution I’ve toyed with is to make the query itself a resource. With this mechanism, GET /airports redirects to a ‘/queries/123/’ resource that contains ‘page’ links to each ‘page’ of the query. But this kind of messes with the notion that GET should return a representation of a resource and not create/update/delete stuff.

By: AsynchronousBlog

AsynchronousBlog — Sat, 19 Feb 2005 23:24:16 +0000

REST Design questions 2 and 3
Dave Megginson continues with his REST design questions. Herein, I respond: Question #2 … Yup, I’ve used query-paramaters in the way you describe to paramaterize a large resource space. I don’t consider it particular inelegant or ugly, but maybe th…

By: Mike Gratton

Mike Gratton — Fri, 18 Feb 2005 03:25:18 +0000

Isn’t this sort of thing what extended XLinks, rather than basic ones, are for? I need to re-read the XLink spec and think about it some more, but it seems like you should be able to use extended XLinks to come up with reasonable XML document that acts as a “cursor” for accessing sub-/child-resources.

By: Quoderat » REST design question #3: meaning of a link

Quoderat » REST design question #3: meaning of a link — Tue, 30 Nov -0001 00:00:00 +0000

[...] information after you have downloaded an XML file; the second design question asked about discovering resources and dealing with long lists of data< [...]