Restrict number of IDs allowed in GET requests

[steveh]

If you specify a large number of, for example, invoice IDs in xero_client.accounting_api.get_invoices you will hit either a 414 or 400 error due to the request URI being too long.

Specifically with 220 IDs we get a HTML 400 error from Akamai, with 210 IDs we get an XML 414 error from Xero, and with 200 IDs we get success.

I think this SDK should either immediately raise an error if you try and request more than say 100 IDs, or better, paginate the requests itself. Or better still, update the API to support these kind of bulk requests with a POST that would not have a URI length restriction.

[SerKnight]

Hi Steveh.

This is a good idea. I've dealt with the URL string exceeding browser limits and it is not clear at first.

In the near term I think putting in clearer SDK errors to limit the user from passing the url limits will be more feasible then new post endpoints, but agreed that is likely the better option, using a POST body.

Feel free to post back ideas you have on how to best solve and will do some more thinking on this, as it is an edge case issue that effects all 6 of our supported SDKs.

[rjaus]

I can't see that we would make API changes to support longer URI's.

Adding some form of validation error in the SDK could be an option, not that it resolves the issue, rather it would inform the developer that an issue exists.

Solutions Discussed:

1. Create a new get_invoices method, or helper method, that accepts an array of ID's and break it down into batches of 100, before making requests for invoices.
2. Add a validation error when the URI reaches a certain length. 200 GUIDs (36 characters) + commas is approximately 7400 characters. We'd need to validate exactly where that limit is, but your issue has narrowed that down (thanks!)
3. Create a a new 'bulk' invoices endpoint which accepts InvoiceID's via the request body to work around the URI length limit.

Of those solutions:

1. Open for discussion. To me It feels like we're asking too much of the SDK. In addition, it somewhat obscures what's actually happening. With multiple requests in play, access tokens could expire between requests. Rate limits could get hit.
2. Easy enough to implement
3. Good solution, but I don't think it's realistic that it would get prioritised on the roadmap within a reasonable period of time.