Tell me more ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.
up vote 0 down vote favorite

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?

share|improve this question

2 Answers

up vote 1 down vote accepted

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.

share|improve this answer
1  
Well 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. Feb 13 '11 at 10:08
up vote 6 down vote

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.

share|improve this answer
+1 I really don't see the benefit of pagination on the /sites results. I'm never going to want only some of the sites; I want all or nothing. – Dave DeLong Feb 12 '11 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. Feb 12 '11 at 19:27
What I've done is create a cron script 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♦ Feb 12 '11 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. Feb 12 '11 at 22:49
Can this be put into feature-request? – Jonathan. Feb 12 '11 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♦ Feb 12 '11 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. Feb 12 '11 at 23:11
@Jonathan: True. This is important because it affects me too. – Nathan Osman♦ Feb 12 '11 at 23:13
@George: I didn't say that it didn't affect you?? – Jonathan. Feb 12 '11 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♦ Feb 12 '11 at 23:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged