6

There's been some grumbling in the past about the unreliability of really ludicrously long URLs sent to the API.

We've always considered this suboptimal, but the underlying technical constraints (http.sys + IIS + .NET 3.5) made fixing this a very arduous endeavor.

Well, ardor has been endured and the API should accept any reasonable construction now.

Be aware that once you go past 100 ids all bets are off as something will kill such requests. If its not the API itself, you'll probably get something unexpected back.

Also be aware that standard HTTP timeouts and the like apply, so really massive requests on expensive routes run the risk of Gateway Timeouts (not to mention whatever client side timeouts you may be imposing or have imposed upon you).

Improve this question
1
  • 2
    ++ pleasing customers is an admirable trait. ;-)
    – Sky Sanders
    Commented Jul 22, 2010 at 17:23

2 Answers 2

Reset to default
1

This has been unfixed. The API is back to its old tricks only accepting around about 30 ids.

Improve this answer
6
  • umm... click the test case above. looks like it is un-unfixed. or de-unfixed.
    – Sky Sanders
    Commented Aug 3, 2010 at 23:23
  • Awh what a headache, that URL didn't work literally 5 minutes ago
    – Igor Zevaka
    Commented Aug 3, 2010 at 23:29
  • 1
    Actually, click on it a few times, sometimes you get HTTP 400. Seems intermittent.
    – Igor Zevaka
    Commented Aug 3, 2010 at 23:31
  • confirmed. and inconsistent is more annoying than just broken ;-)
    – Sky Sanders
    Commented Aug 3, 2010 at 23:41
  • we added a new server and this requires a manual step to make this change. url lengths are now back to "crazy long"
    – Geoff Dalgas
    Commented Aug 4, 2010 at 0:16
  • Thanks, this should help. My app is now failing Jon Skeet test miserably - requesting in batches of 30 :(
    – Igor Zevaka
    Commented Aug 4, 2010 at 0:34

You must log in to answer this question.

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