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

101–110 of 258 posts

Re: API Practices If You Hate Your Customers

#101

Post by kelnos »

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.

Responding politely could also teach the junior that it's ok to act like an asshole, because he'll get a polite response no matter what.

I suppose the ideal response would have been a polite correction, followed by a polite rebuke regarding the junior's tone and behavior, but I can't fault someone for responding to fire with fire on occasion.

Re: API Practices If You Hate Your Customers

#102

Post by zonidjan »

celticmusic wrote: post #91
wwweston wrote: post #88

Earlier quoted context omitted.

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.

Whether there's a bug in the underlying API code, or a bug in the web server, there's a risk that it "may or may not result in the standard response format you're expecting", and therefore... should be a 500 error.

Yes, using the wrong status codes is a problem, you're right, that's the entire point of the thread you're responding to.

Re: API Practices If You Hate Your Customers

#103

Post by AgentME »

paulddraper wrote: post #58
Glyptodon wrote: post #19

I thought the chosen example for idempotent requests was a bit funny as I don't think POST is necessarily idempotent and depending on your specific use case making it so may or may not be easy.

POST is explicitly not idempotent.

POST isn't required to be idempotent, but to be clear it's not improper to make an API with idempotent POST endpoints.

Re: API Practices If You Hate Your Customers

#104

Post by celticmusic »

zonidjan wrote: post #102
celticmusic wrote: post #91

Earlier quoted context omitted.

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.

Whether there's a bug in the underlying API code, or a bug in the web server, there's a risk that it "may or may not result in the standard response format you're expecting", and therefore... should be a 500 error . Yes, using the wrong status codes is a problem, you're right, that's the entire point of the thread you're responding to.

that's flat out not true, it's a red herring.

I can't think of very many tech stacks where an error inside the API couldn't be trapped and responded with a standard json response.

Re: API Practices If You Hate Your Customers

#106

Post by hnick »

couchand wrote: post #98
hnick wrote: post #80

Earlier quoted context omitted.

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.

I'd weigh that up against the very real risk it is mis-configured by someone's nephew and exposes my private data to anyone who asks.

I think mandating API for certain industries like banking is a good idea, but I'm not so supportive of having it apply all the way down to my local hair salon. They have enough to worry about.

Re: API Practices If You Hate Your Customers

#108

Post by TrackerFF »

sergiotapia wrote: post #4

A pretty bogus article. If you can charge for an API and people are paying for it, why would you not charge for it? If people aren't paying then think about making it free and making it a doorway into your general product.

I think that if your product is something which is available (by browsing, for example), but you only offer a very expensive API - no stripped down free use - you're setting yourself up to both web scrapers, and giving away potential customers to the competition.

Re: API Practices If You Hate Your Customers

#109

Post by JackRabbitSlim »

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…

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.

Re: API Practices If You Hate Your Customers

#110

Post by nobleach »

iamthepieman wrote: post #42
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…

This isn't the ArcGIS Server API is it?

Man that thing is a mess, isn't it....
Post reply on HN