Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Mistakes Made by API Providers

readwriteweb.com

Post reply on HN
Print view View original

11–14 of 14 posts

Re: Common Mistakes Made by API Providers

#11

Post by njharman »

wccrawford wrote: post #9

I found some unexpected wisdom, along with a lot of things I agree with. "If you haven't built your website on top of your API, consider doing that -- or at least what it would be LIKE to do that. If your API couldn't reproduce your website, your API needs fixing." At first, I was going to argue with this. But then I realized: You don't have to actually -do- it, just write like you would. You don't have to give third…

BBC (I think or maybe it was PBS|NPR) did this. Recent article talked about how they decided to go "open" and put everything in API. Later on when developing for satelite stations and other projects they found using their API was the bestest, fastest way to go.

Re: Common Mistakes Made by API Providers

#13

Post by cheald »

mootothemax wrote: post #3

Twitter is the absolute best case study for this. I love that a response that should return XML or JSON formatted data returns the fail whale in all its HTML glory when they're overloaded. I still don't understand how in their mind that's more efficient than a 503 http response.

Chances are that they've got something like HAProxy running in front of their application backends, and you get a shirnkwrapped 503 page back when no backend can be reached. In that case, the application can't intelligently decide to return a json response because the application never gets the request.

Re: Common Mistakes Made by API Providers

#14

Post by thwarted »

cheald wrote: post #13
mootothemax wrote: post #3

Twitter is the absolute best case study for this. I love that a response that should return XML or JSON formatted data returns the fail whale in all its HTML glory when they're overloaded. I still don't understand how in their mind that's more efficient than a 503 http response.

Chances are that they've got something like HAProxy running in front of their application backends, and you get a shirnkwrapped 503 page back when no backend can be reached. In that case, the application can't intelligently decide to return a json response because the application never gets the request.

While API clients should be able to interpret the HTTP response code, 503 in this case, in a meaningful way, the API should have internal status/success codes that the body of the 5xx responses can contain.

Using haproxy to load balancer is no excuse for this, as you can tell haproxy to serve custom error documents using the errorfile option, and these error documents can be json or XML. And you can use layer 7 routing in haproxy to allow different configurations based on what the request looks like (in the case of, say, you were dumb and put everything your site does on a single domain, rather than putting the api on a different IP/subdomain).

Post reply on HN