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.

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.

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. {SITE} .com/1.1/multiple

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.

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.