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

API Practices If You Hate Your Customers

queue.acm.org

Post reply on HN
Print view View original

81–90 of 258 posts

Re: API Practices If You Hate Your Customers

#81

Post by rsynnott »

Fradow wrote: post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

> I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors.

I've done something like this in the past. There was a (horrible) reason; old versions of Android had terrible built-in HTTP stuff and tended to break on any 'unusual' HTTP responses (for instance, 204), especially where HTTP compression was enabled. By far the safest way to support clunky old Androids turned out be be just return 200 for everything with the real code embedded elsewhere...

Re: API Practices If You Hate Your Customers

#82

Post by eecc »

Fradow wrote: post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

Sounds familiar... ugh

Re: API Practices If You Hate Your Customers

#83

Post by celticmusic »

Fradow wrote: post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

> When pointed out, the support answer was "we chose to give meaningful error messages instead of HTTP codes, that's why we respond with 200 in case there's an error in the request". Not the answer I was expecting.

I don't see the problem here. As a developer I'd much rather receive a standard json packet with information helping me figure out what went wrong.

I really don't understand your complaint here, I've designed and worked with both types of API's, and I find the standard json format to be far easier to deal with.

Re: API Practices If You Hate Your Customers

#84

Post by peterwwillis »

6gvONxR4sf7o wrote: post #47

I only ever use internal APIs at work. I've never used anyone's external APIs and am wondering if there's a whole tech ecosystem I'm missing out on. What are some commercial use cases you all have had?

From an ops perspective, many *aaS providers simply don't have working features that we need, so we use their API and build our own solution.

From a dev perspective, there are industry standard APIs which a range of products support, and to design a new product that we want to sell, we have to use said APIs and work with different providers and customers. There are so many differing APIs to do the same thing that we have an internal team whose job is to write an internal API that internal customers use to interface with all the external APIs. This model scales well, as this API-of-APIs team can integrate new solutions transparently to the internal customers, so we don't have to rewrite products just because an external API/provider/customer/etc changed. (back in the day this was with straight databases and apps, and the intermediate layer was called "db apps", and was basically an early API)

Re: API Practices If You Hate Your Customers

#85

Post by pirsquare »

I've worked with plenty of APIs (> 50). The biggest headaches I came across are bureaucratic stuffs rather than poor API designs. For example, there are vendors (like ConstantContact) that requires you to provide your credit card to get an account for API testing. You know what, they auto-bill your card after X number of days and require you to call them up to cancel your subscription. Because I'm on the other side of the world, I've to drop them a call in the middle of the night just to cancel billing.

Re: API Practices If You Hate Your Customers

#86

Post by skunkworker »

Fradow wrote: post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

I had that when I was dealing with the Withings API. Oh you got a 4XX error? Here is a 200 back with a json payload of {error: 400, message: "Some message"}.

Ugh it was frustrating.

Re: API Practices If You Hate Your Customers

#87

Post by saagarjha »

gamblor956 wrote: post #63
saagarjha wrote: post #41

Earlier quoted context omitted.

There's no need to shame people who are wrong.

Normally that would be true. But it's necessary to shame people who work the trade desks, or else they will never learn.

I honestly think people learn better if you don't shame them.

Re: API Practices If You Hate Your Customers

#88

Post by wwweston »

celticmusic wrote: post #83
Fradow wrote: post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

> When pointed out, the support answer was "we chose to give meaningful error messages instead of HTTP codes, that's why we respond with 200 in case there's an error in the request". Not the answer I was expecting. I don't see the problem here. As a developer I'd much rather receive a standard json packet with information helping me figure out what went wrong. I really don't understand your complaint here, I've desig…

Totally agree that specific messaging is very convenient, but meaningful error messages and meaningful status codes aren't even remotely mutually exclusive. It's perfectly legitimate and even easy to send a 4xx or 5xx with a response body as JSON (or, for bonus points, with any other content type the client requests from possible server capabilities).

And in my experience, having an out-of-body/band general indicator that doesn't require you to parse message responses makes things WAY easier.

Well-designed APIs do both.

Re: API Practices If You Hate Your Customers

#89

Post by jventura »

celticmusic wrote: post #83
Fradow wrote: post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

> When pointed out, the support answer was "we chose to give meaningful error messages instead of HTTP codes, that's why we respond with 200 in case there's an error in the request". Not the answer I was expecting. I don't see the problem here. As a developer I'd much rather receive a standard json packet with information helping me figure out what went wrong. I really don't understand your complaint here, I've desig…

You can return a 400 and still return a json payload in the http message body. Maybe is that what the parent is saying?

Re: API Practices If You Hate Your Customers

#90

Post by kelnos »

saagarjha wrote: post #41
gruez wrote: post #39

Earlier quoted context omitted.

>Surely there must have been a better way for you to handle this situation. The junior was in the wrong, so I think you'd agree that a correction is in order. Replying-all is one way to do such a correction. The alternative would be to force him to issue a retraction himself.

There's no need to shame people who are wrong.

True. If the junior dev was simply wrong, but polite about it, it might (and should) have ended without a shaming.

While there is perhaps no need to shame someone who is acting in a shameful way, I find it hard to criticize someone for doing so. Sometimes an aggressive statement deserves an aggressive response.

Post reply on HN