Skip to main content
added 361 characters in body; edited title
Source Link

URL Length Limit on the number of vectorized ids for requests likeFor For Requests Taking Vectorised Ids (/answers/{id}, /questions/{id}, etc)

I am trying to use /questions/{id} API to get a list of questions by their ids. Help page for this request does not indicate the maximum number of ids that can be passed in. Pagesize is maximum 100, so I started off with 100 and got a "HTTP Error 400. The request URL is invalid." Same with 50, however 20 is OK.

The question is whether or not there should be a published limit on number of ID parameters on the API help page and what it is. I didn't want to start hitting the server doing a binary search between 20 and 50 and I think it's in the interest of the community to know about how this is supposed to work.

Background I am doing an app that tracks tags that the user is active in over time, so I need to get to the tags (which are in the Question object) by questionId, which is in the Answer object.

So the workflow is currently like this:

  1. Request user's answers by user id - {Number of answers}/100 requests (300 answers - 3 requests).
  2. Requests a list of questions corresponding to each questionId from above. {Number of answers}/20 (20 is the number of requests that I know works) (300 answers - 15 requests).

This is not very efficient so I would like to know what the maximum number is, so I can minimise the number of requests.

Here is a sample URL (462 characters).

Update The failed request is due to a server rejecting a long URL, which is evident due to response code 400 and presence of payload (Also there are no ASP.NET headers on the response, so I think it's one of the proxies rejecting it before it even hits the web server).

The updated question is what is the limit on the URL length for StackApps sites?

Limit on the number of vectorized ids for requests like /answers/{id}, /questions/{id}, etc

I am trying to use /questions/{id} API to get a list of questions by their ids. Help page for this request does not indicate the maximum number of ids that can be passed in. Pagesize is maximum 100, so I started off with 100 and got a "HTTP Error 400. The request URL is invalid." Same with 50, however 20 is OK.

The question is whether or not there should be a published limit on number of ID parameters on the API help page and what it is. I didn't want to start hitting the server doing a binary search between 20 and 50 and I think it's in the interest of the community to know about how this is supposed to work.

Background I am doing an app that tracks tags that the user is active in over time, so I need to get to the tags (which are in the Question object) by questionId, which is in the Answer object.

So the workflow is currently like this:

  1. Request user's answers by user id - {Number of answers}/100 requests (300 answers - 3 requests).
  2. Requests a list of questions corresponding to each questionId from above. {Number of answers}/20 (20 is the number of requests that I know works) (300 answers - 15 requests).

This is not very efficient so I would like to know what the maximum number is, so I can minimise the number of requests.

Here is a sample URL (462 characters).

URL Length Limit For For Requests Taking Vectorised Ids (/answers/{id}, /questions/{id}, etc)

I am trying to use /questions/{id} API to get a list of questions by their ids. Help page for this request does not indicate the maximum number of ids that can be passed in. Pagesize is maximum 100, so I started off with 100 and got a "HTTP Error 400. The request URL is invalid." Same with 50, however 20 is OK.

The question is whether or not there should be a published limit on number of ID parameters on the API help page and what it is. I didn't want to start hitting the server doing a binary search between 20 and 50 and I think it's in the interest of the community to know about how this is supposed to work.

Background I am doing an app that tracks tags that the user is active in over time, so I need to get to the tags (which are in the Question object) by questionId, which is in the Answer object.

So the workflow is currently like this:

  1. Request user's answers by user id - {Number of answers}/100 requests (300 answers - 3 requests).
  2. Requests a list of questions corresponding to each questionId from above. {Number of answers}/20 (20 is the number of requests that I know works) (300 answers - 15 requests).

This is not very efficient so I would like to know what the maximum number is, so I can minimise the number of requests.

Here is a sample URL (462 characters).

Update The failed request is due to a server rejecting a long URL, which is evident due to response code 400 and presence of payload (Also there are no ASP.NET headers on the response, so I think it's one of the proxies rejecting it before it even hits the web server).

The updated question is what is the limit on the URL length for StackApps sites?

added 513 characters in body
Source Link

I am trying to use /questions/{id} API to get a list of questions by their ids. Help page for this request does not indicate the maximum number of ids that can be passed in. Pagesize is maximum 100, so I started off with 100 and got a "HTTP Error 400. The request URL is invalid." Same with 50, however 20 is OK.

The question is whether or not there should be a published limit on number of ID parameters on the API help page and what it is. I didn't want to start hitting the server doing a binary search between 20 and 50 and I think it's in the interest of the community to know about how this is supposed to work.

Background I am doing an app that tracks tags that the user is active in over time, so I need to get to the tags (which are in the Question object) by questionId, which is in the Answer object.

So the workflow is currently like this:

  1. Request user's answers by user id - {Number of answers}/100 requests (300 answers - 3 requests).
  2. Requests a list of questions corresponding to each questionId from above. {Number of answers}/20 (20 is the number of requests that I know works) (300 answers - 15 requests).

This is not very efficient so I would like to know what the maximum number is, so I can minimise the number of requests.

Here is a sample URL (462 characters).

I am trying to use /questions/{id} API to get a list of questions by their ids. Help page for this request does not indicate the maximum number of ids that can be passed in. Pagesize is maximum 100, so I started off with 100 and got a "HTTP Error 400. The request URL is invalid." Same with 50, however 20 is OK.

The question is whether or not there should be a published limit on number of ID parameters on the API help page and what it is. I didn't want to start hitting the server doing a binary search between 20 and 50 and I think it's in the interest of the community to know about how this is supposed to work.

Background I am doing an app that tracks tags that the user is active in over time, so I need to get to the tags (which are in the Question object) by questionId, which is in the Answer object.

So the workflow is currently like this:

  1. Request user's answers by user id - {Number of answers}/100 requests (300 answers - 3 requests).
  2. Requests a list of questions corresponding to each questionId from above. {Number of answers}/20 (20 is the number of requests that I know works) (300 answers - 15 requests).

This is not very efficient so I would like to know what the maximum number is, so I can minimise the number of requests.

I am trying to use /questions/{id} API to get a list of questions by their ids. Help page for this request does not indicate the maximum number of ids that can be passed in. Pagesize is maximum 100, so I started off with 100 and got a "HTTP Error 400. The request URL is invalid." Same with 50, however 20 is OK.

The question is whether or not there should be a published limit on number of ID parameters on the API help page and what it is. I didn't want to start hitting the server doing a binary search between 20 and 50 and I think it's in the interest of the community to know about how this is supposed to work.

Background I am doing an app that tracks tags that the user is active in over time, so I need to get to the tags (which are in the Question object) by questionId, which is in the Answer object.

So the workflow is currently like this:

  1. Request user's answers by user id - {Number of answers}/100 requests (300 answers - 3 requests).
  2. Requests a list of questions corresponding to each questionId from above. {Number of answers}/20 (20 is the number of requests that I know works) (300 answers - 15 requests).

This is not very efficient so I would like to know what the maximum number is, so I can minimise the number of requests.

Here is a sample URL (462 characters).

Source Link

Limit on the number of vectorized ids for requests like /answers/{id}, /questions/{id}, etc

I am trying to use /questions/{id} API to get a list of questions by their ids. Help page for this request does not indicate the maximum number of ids that can be passed in. Pagesize is maximum 100, so I started off with 100 and got a "HTTP Error 400. The request URL is invalid." Same with 50, however 20 is OK.

The question is whether or not there should be a published limit on number of ID parameters on the API help page and what it is. I didn't want to start hitting the server doing a binary search between 20 and 50 and I think it's in the interest of the community to know about how this is supposed to work.

Background I am doing an app that tracks tags that the user is active in over time, so I need to get to the tags (which are in the Question object) by questionId, which is in the Answer object.

So the workflow is currently like this:

  1. Request user's answers by user id - {Number of answers}/100 requests (300 answers - 3 requests).
  2. Requests a list of questions corresponding to each questionId from above. {Number of answers}/20 (20 is the number of requests that I know works) (300 answers - 15 requests).

This is not very efficient so I would like to know what the maximum number is, so I can minimise the number of requests.