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

171–180 of 258 posts

Re: API Practices If You Hate Your Customers

#171

Post by doppel »

dullroar wrote: post #113

Here's one from a vendor I currently integrate with - have multiple APIs (in this case, a SOAP one, a REST one returning JSON, and then some language SDKs that wrap the latter for convenience), and have their feature sets be an interesting Venn diagram with various intersections but no unions. Just today I found out that the in the extensive integration we've written using the SDK (which wraps the REST API, remember)…

Same situation with private beta features, which "can not" be officially supported in the official SDK for the product.

Re: API Practices If You Hate Your Customers

#172

Post by Aeolun »

ergothus wrote: post #74
dx87 wrote: post #34

Earlier quoted context omitted.

I'm not seeing anything wrong with what OP did. By CCing everyone, the junior is trying to make themselves look good by making OP look bad. The junior learned that if they act like an ass, especially an incorrect ass, the other employees won't tolerate it.

That's the DESIRE for what the junior learned. But is that what they actually learned? One could just as easily (or more easily) decide instead that this is the way business is done. It's literally all they've ever seen.

So what they've learned is, if someone makes an incorrect assumption, sends a nasty email, and CCs the entire department, I get to respond by sending an email back pointing out their error and CCing an even larger audience.

I don't think that's necessarily a bad thing to learn, even for the junior...

Re: API Practices If You Hate Your Customers

#173

Post by NicoJuicy »

rsynnott wrote: post #136
NicoJuicy wrote: post #131

Earlier quoted context omitted.

Ugh, i'd put a gateway in front of it that transformed the status codes to a 200-response. Instead of building your api according to the default Android client ( ps. Lookup BFF microservices)

It was a while ago, and we were very cost sensitive. FWIW, I think the last Android phones with these client issues have probably died by now (it got mostly sorted out in 4.3 or so IIRC); this isn't a current concern.

Just pointing out an alternative that wouldn't break/uglify your api ;)

Re: API Practices If You Hate Your Customers

#174

Post by oftenwrong »

wool_gather wrote: post #135
JackRabbitSlim wrote: post #109

Earlier quoted context omitted.

A huge and borderline criminal conflation with HTTP in general and REST-y APIs. The big fat elephant in all this is simple; None of our fucking opinions matter one god damn bit to the end client. Being originally designed to you know, consume hypertext over the hypertext transfer protocol, clients can and will do whatever the fuck they want with the status codes.

Well, speaking as a client developer, the API is far, far easier for me to understand and write logic against if its authors agree to send back HTTP statuses with their standardized meanings instead of making up their own scheme.

HTTP statuses have no "standardized meanings" at the application level.

Re: API Practices If You Hate Your Customers

#175

Post by Moru »

arethuza wrote: post #165
scarejunba wrote: post #96

Earlier quoted context omitted.

I've noticed that if you stay strictly professional, folks think higher of you and they feel shame for having done this. You also appear way wiser and likeable - all of which gives you more clout. And if you're more often right than your peers, everyone benefits by your having more clout. I've been in this situation before and I've found this approach beneficial.

"I've noticed that if you stay strictly professional, folks think higher of you and they feel shame for having done this." Some do, some think it is a sign of weakness and start behaving even more unreasonably.

And since the boss knows you are right because of your previous behaviour, all you need to do is ask the boss to take care of the disturbing element if it continues.

Re: API Practices If You Hate Your Customers

#176

Post by wokkel »

I'm missing a few in the list: 1) Have an API but only expose that via some weird-ass tool instead of a normal protocol. 2) Have a lot of documentation but make it so bad it's useless (looking at Telebib2 right now) 3) Only return generic errors which are always the same 4) Refer to standards so you don't have to document them, but then deviate slightly so all standard tools don't work 5) Make it ambiguous (best one I've seen so far: 30% of the required fields must be filled in, doesn't matter which 30%).

I could go on looking back the projects I've done.

Re: API Practices If You Hate Your Customers

#177

Post by donkeyd »

gtsteve wrote: post #2

I was expecting to see two of my pet hates - returning a null array to represent no items, and returning a single object without an array to represent one item. I also once worked with an API where you had to send the data in POST format - abc=123&def=456. After much pressure from their customers, they finally relented and added an XML version of their API... where your request could look like this: abc=123&def=456 .…

I worked with a product for natural language processing that wanted the text in a query string. This led to 100+ page documents begin sent as a string in the request. My usual REST testing app would freeze up if I wanted to test some of the largest documents in the data set.

Re: API Practices If You Hate Your Customers

#178

Post by jeltz »

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 have integrated against many weird B2B APIs and those who always return 200 are actually pretty nice to work with so even if it is a weird choice as an API consumer I do not mind it all, there are much worse things you can do.

Re: API Practices If You Hate Your Customers

#179

Post by lazyasciiart »

yardstick wrote: post #169
lazyasciiart wrote: post #158

Earlier quoted context omitted.

With a 200 your client won't know they've done anything wrong without debugging either. There is nothing preventing you from returning a detailed error message with your 404.

If under your suggestion you have to look at the details of a 404 anyway to get a detailed error message, what is the point of the 404? Your client always has to do an explicit check for error/no-error. Why make them check two different locations? Just always look at the body: one location.

You don't have to. Plenty of times, a 404 is all I need to know. Why make the client check two different locations?

Re: API Practices If You Hate Your Customers

#180

Post by sho »

jayd16 wrote: post #162
wool_gather wrote: post #71

Earlier quoted context omitted.

This is what the 400 and 500 ranges of HTTP status codes are for. The former when the problem is on the client side, the latter for a problem on the server. And you can still send a descriptive body for the error, if you so choose.

This is not true. Counterpoint, responses like 404 or 503 Bad Gateway do not come from the destination server. They do not indicate the intended server received your request.

404 and 500 should come from the destination server. You are correct that 503 would not.
Post reply on HN