So I just spent two hours wrestling with MapQuest’s .NET API and trying to figure out why I couldn’t connect to the web, through a proxy, using their API.
After a reflector session, several spikes, and more than a few packet sniffs, I finally figured out WHY it wasn’t working: the MapQuest API has a bug. Actually two.
Breaking down the MapQuest API uncovers two bugs:
- MapQuest constructs their own, raw HTTP Request as opposed to using the standard .NET BCL objects, and they didn’t test their proxy code, so the HTTP request doesn’t construct the proxy section correctly.
- MapQuest implements their own Base64 scheme, again, as opposed to using the standard .NET BCL, which, you guessed it, doesn’t encode correctly.
Why, oh why did MapQuest implement their API this way? Because they didn’t “implement” it, they converted it. That’s right, they took their Java API, and ran it through the JLCA. You only have to look at far as their “Collection” objects. Not only do they not support enumeration via IEnumerable, but their API is the same horrible java collection based API: GetAt(int), Size(), etc…
Horrible, just horrible, and the fact that it’s a company the size of MapQuest just makes it worse.
Come Tuesday, my only option may be to decompile the .NET assembly, fix the HTTP request construction, and recompile and use that. That’s a bad solution because if MapQuest releases a new version, we’d be screwed.
Or I could try and contact MapQuest, and see if they could fix the bug. HA! We’ll see how that goes.