Take the 2-minute tour ×
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.

I've been doing a lot of work on StackMobile lately and I made the following observation:

Many of the pages (especially the ones that display a user's profile) make a number of requests to display the content for that page. For example, to display a user's profile, the following routes are hit (keep in mind that these requests are all made to display one page):

  • http://api.{SITE}.com/1.1/users/{ID}
  • http://api.{SITE}.com/1.1/users/{ID}/questions?sort=votes&pagesize=5
  • http://api.{SITE}.com/1.1/users/{ID}/answers?sort=votes&pagesize=5
  • http://api.{SITE}.com/1.1/users/{ID}/badges
  • http://api.{SITE}.com/1.1/users/{ID}/tags

Note: caching might provide a very small relief - but hardly noticeable due to the sheer number of different profile pages being requested.

I was wondering if it would be possible to issue a single request that would contain multiple queries and have the results returned in a special object that contained each of the responses. For example, perhaps there could be a new route like:

http://api.stackexchange.com/{VERSION}/multiple?site={SITE}

POST parameters:

{
  "queries":
  [
    "/users/1/questions",
    "/users/1/answers"
  ]
}

Results:

{
  "results":
  [
    {
      "query": "/users/1/questions",
      "response": { ...... }
    },
    {
      "query": "/users/1/answers",
      "response": { ...... }
    }
  ]
}

This is just a suggestion for how such a thing would be implemented. The benefit to the application developer is obvious: when making blocking HTTP requests, there is only a need to wait for one request instead of 5 (as in my example above). Stack Exchange would benefit as well from the reduction in requests and bandwidth because fewer HTTP headers would need to be sent out and there would be less network overhead.

In summary, this is just an idea I had floating around in my head for a while that I wanted to get down before I forgot it - but I think it would be a nice feature to include in a future API release.

share|improve this question
    
I don't if it would be possible, but I'd like to be able to choose what is returned, so if you call http://api. {SITE} .com/1.1/users/ {ID} you can set either through HTTP header fields or URL parameters or POSTing some JSON, what fields you want to be returned, eg you might only want the user's display name, and nothing else, but you might what their favourite questions, tags, etc all in one. –  Jonathan. Jun 29 '11 at 16:27
    
@Jonathan: That would be nice too but one thing at a time :) –  Nathan Osman Jun 30 '11 at 1:19
    
yes I know :) thats why I commented :). But it would solve your problem, use less bandwidth, and be more efficient, in one swoop. –  Jonathan. Jun 30 '11 at 12:57
    
@Jonathan: I found this quote here: "...and for the ability to request only a subset of the fields on an object..." –  Nathan Osman Jul 2 '11 at 19:16
    
Thanks nice to know it's in the [rather long] pipeline :) –  Jonathan. Jul 2 '11 at 19:35

You must log in to answer this question.

Browse other questions tagged .