Due to the new pagination of the /sites method in v1.1 of the API, we have to go through all the pages of sites to check whether a site exists, or allow the user to search for a site.
Would it be possible to provide a way to search the list instead?
Add a comment |
2 Answers
Pagination on /sites is solely so [app]s don't have to pull down any unknown, large, and constantly growing chunk of a data in a single request.
It is expected that every consumer would grab all sites in a series of sequential (or concurrent, if they're comfortable with that) requests for each page.
- 1Well please keep the 1.0 version, during 2.0 and beyond. The pagination makes no sense. When would an app only show one page of sites? you say that you'd expect every consumer would make multiple requests? Surely it's better to avoid the multiple requests?Jonathan.– Jonathan.2011-02-13 10:08:51 +00:00Commented Feb 13, 2011 at 10:08
For now, as we have only ~80 sites, you can set pagesize to 100 and get them all.
But in general, I think pagination here makes no sense at all. Because there're no search parameters or ordering, I can't think of a situation where app can fetch only first page and be satisfied.
Would it be possible to provide a way to search the list instead?
I would propose just getting the whole list of sites, caching it (as documentation recommends) and searching locally.
- +1 I really don't see the benefit of pagination on the
/sitesresults. I'm never going to want only some of the sites; I want all or nothing.Dave DeLong– Dave DeLong2011-02-12 19:17:01 +00:00Commented Feb 12, 2011 at 19:17 - Same I think pagination is a waste of bandwidth, in that it adds a few lines at the top, also it wastes effort.Jonathan.– Jonathan.2011-02-12 19:27:15 +00:00Commented Feb 12, 2011 at 19:27
- What I've done is create a
cronscript that runs every 24 hours, polls/sites, and sticks the results into a MySQL database. That way I can search, re-order, and do all manner of things with it.Nathan Osman– Nathan Osman2011-02-12 20:38:16 +00:00Commented Feb 12, 2011 at 20:38 - @George; but how does that affect the pagination? The script still has to multiple requests (at least it will do when there's more than 100 sites, and if you take a look at Area 51 that's going to happen pretty soon)Jonathan.– Jonathan.2011-02-12 22:49:31 +00:00Commented Feb 12, 2011 at 22:49
- Can this be put into feature-request?Jonathan.– Jonathan.2011-02-12 22:49:51 +00:00Commented Feb 12, 2011 at 22:49
- @Jonathan: Well, just issue enough requests to get all of the sites or use v1.0 of the API, which returns all of them no matter how many there are.Nathan Osman– Nathan Osman2011-02-12 22:53:08 +00:00Commented Feb 12, 2011 at 22:53
- @George: it seems one of the points in 1.1 was to reduce the amount of traffic, so making you do more requests, increases the traffic and makes it more complicated. And while 1.0 is around now, when 2.0 is available the style of 1.1 is more than likely going to be used. It's easier to get it changed when it's new.Jonathan.– Jonathan.2011-02-12 23:11:33 +00:00Commented Feb 12, 2011 at 23:11
- @Jonathan: True. This is important because it affects me too.Nathan Osman– Nathan Osman2011-02-12 23:13:41 +00:00Commented Feb 12, 2011 at 23:13
- @George: I didn't say that it didn't affect you??Jonathan.– Jonathan.2011-02-12 23:25:28 +00:00Commented Feb 12, 2011 at 23:25
- 1@Jonathan: It does affect me - and it affects you too. I'm just saying that in the meantime, I have a method for dealing with this.Nathan Osman– Nathan Osman2011-02-12 23:27:35 +00:00Commented Feb 12, 2011 at 23:27