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

91–100 of 258 posts

Re: API Practices If You Hate Your Customers

#91

Post by celticmusic »

wwweston wrote: post #88
celticmusic wrote: post #83

Earlier quoted context omitted.

> 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…

I'm curious, what tech stack are you working in where parsing json is difficult?

You want to talk about inconsistent? How about a 500 error may or may not result in the standard response format you're expecting because it may be coming from the server and it may be coming from the API.

I'd much rather my 500 errors be legitimate server problems.

Re: API Practices If You Hate Your Customers

#92

Post by lmm »

favorited wrote: post #28
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 .…

There's often a semantic difference between null and empty. Like, if I'm checking the result of a batch processing job, I want to know if the job finished & resulted in an empty set, or there is simply no result yet. It's "the thing you're looking for doesn't exist" vs. "the thing you're looking for exists, but is empty."

Right, which is why it's really confusing when an API returns null to mean empty.

Re: API Practices If You Hate Your Customers

#93

Post by vortico »

jbob2000 wrote: post #3

This article is junk. There are many reasons for not offering an API to customers. I run a small b2b app between two completely non-technical businesses. There is absolutely no need for me to have an API available to them, they’ve never asked for it and have no desire or ability to consume it. Believe it or not, there is also an expense to offering an API! An API is a product offering like anything else, and products…

Not sure why you're being downvoted. An API is a feature just like any other features your company offers. If 1000 customers/clients ask for feature A and 0 ask for feature B, it's obvious you shouldn't waste your time on B. If B = "an API", and it doesn't change that it's a waste of time in this scenario.

Re: API Practices If You Hate Your Customers

#94

Post by kelnos »

tbirdz wrote: post #24
hermitdev wrote: post #18

Earlier quoted context omitted.

> returning a null array to represent no items, and returning a single object without an array to represent one item. This just reminded me of a long ago incident at a former employer. I worked in back-office at a hedge fund and was responsible for maintaining several APIs & services written in C++. The APIs were pretty straight forward query for object(s), get back a vector of objects. If nothing was found, you'd ge…

I really don't like your story. The junior is clearly behaving immaturely and inappropriately by CCing others and not using an appropriate tone, but your response is to... retaliate by doing the exact same thing to him? What lesson is the junior supposed to learn here? That acting that way is A-OK as long as you have seniority and are factually correct? At least the junior has the "excuse" of being a junior, but real…

I fundamentally disagree with the idea that it's a virtue to act politely and "professionally" in all circumstances, no matter what the provocation. I think it can be entirely reasonable (depending on specific circumstances) to publicly shame someone who has been publicly acting like an asshole.

Simply being wrong in public deserves a gentle correction (possibly in private, again, depending on the circumstances), but often I don't really care to be nice to people who aren't being nice. It's certainly possible that being nice all the time in situations like this gets you better outcomes overall, but we all have a limited amount of patience to dole out, and some people just don't deserve it sometimes.

And on the other hand, some people don't get the message when you respond politely. Responding politely in this case could just as easily teach the junior that his debugging strategy (blame anyone but himself) and dickish tone were completely ok. There's certainly a polite way to inform the junior that his behavior won't be tolerated, but I can't fault someone for simply responding in kind.

Re: API Practices If You Hate Your Customers

#95

Post by james_s_tayler »

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…

Monitoring tools logging request/response payloads are just going to look at status codes. Breaking that kind of stuff cos you wanted to do it your way sucks.

Re: API Practices If You Hate Your Customers

#96

Post by scarejunba »

shantly wrote: post #61
saagarjha wrote: post #41

Earlier quoted context omitted.

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

If they're trying to shame or chastise others, while being wrong, seems fair to me. Then again, I subscribe to the "play stupid games, win stupid prizes" school of dickish behavior correction. Or, to defer to the ever-wise Gods of the Copybook Headings: "What's good for the goose is good for the gander".

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.

Re: API Practices If You Hate Your Customers

#97

Post by celticmusic »

james_s_tayler wrote: post #95
celticmusic wrote: post #83

Earlier quoted context omitted.

> 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…

Monitoring tools logging request/response payloads are just going to look at status codes. Breaking that kind of stuff cos you wanted to do it your way sucks.

I guess I've never worked with a monitoring tool that didn't support deserializing json and looking for specific data.

Re: API Practices If You Hate Your Customers

#98

Post by couchand »

hnick wrote: post #80
tomaszs wrote: post #26

Personally i think API should be obligatory. Every company should provide it with respect for private data. Additionaly if a company does not have it, it should be prohibited to block automatic measures to process the system and data. There should be a pricing model to cover basic expenses made by the API usage. Maybe you wonder why on earth it should be legally allowed to process automatically system data? We have a…

Does "every company" include the thousands of local businesses running Woocommerce or Shopify? Larger companies love regulations like this because they can afford it, and it keeps smaller competitors from ever growing to be a threat. I'm not saying they should be able to do whatever with data - but for such providers, manually replying to an email is preferable than implementing a complicated technical solution they…

Clearly if this regulation existed companies like the ones you mention would include an API as part of their offering.

Re: API Practices If You Hate Your Customers

#99

Post by zonidjan »

reificator wrote: post #76
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…

IIRC cross domain requests are often one of the causes for this style of API design. I remember in older browsers at least anything not in 2XX would be unreadable by the client, so they had no idea what actually went wrong on the frontend.

That's... extremely rare, extremely ancient, and even then was usually only a problem below a certain page length.

Re: API Practices If You Hate Your Customers

#100

Post by peterwwillis »

inputespresso wrote: post #33
NedIsakoff wrote: post #6

I really liked Strip's API version scheme and how well done it is. Recently I'm writing code that interacts with API of a Enterprise Product (fairly new, less then 3 years old) and its driving me crazy. They version every single API endpoints separately. So endpoint A to create a user is at version 7 but endpoint B to assign a group to a user is at version 4. WTF?

Stripe's API is well documented, but I don't understand why it uses form data instead of JSON. Seems weird/scary to have an API driven by completely unstructured text.

It is structured. The first page of the Stripe API links to the encoding standards. The main difference between it and JSON is JSON supports complex data structures while form encoding is flat key-values. In fact, with RFC7578, multipart/form-data encoding allows arbitrary Unicode strings, unlike JSON, which requires weird handling of some Unicode data.
Post reply on HN