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

151–160 of 258 posts

Re: API Practices If You Hate Your Customers

#151

Post by Fradow »

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?

No this isn't. Without calling out names, the first one is a small localization platform (but seems to be a very prevalent issue in multiple APIs) and the second is an international hosting provider. Both are good enough for my case to overlook those issues, that are nevertheless infuriating.

Re: API Practices If You Hate Your Customers

#152

Post by donmatito »

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…

Slack API does that too

(to their credit, the docs are very complete and clear, even if their API design is questionable)

Re: API Practices If You Hate Your Customers

#153

Post by dualscyther »

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've found that returning 200 with errors seems to be the sane way to do things, since sometimes it's difficult to tell whether a server error belongs in the http later or graphql layer.

Re: API Practices If You Hate Your Customers

#154

Post by yardstick »

wwweston wrote: post #130
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.

While we're asking questions: what stack out there makes reading/writing HTTP headers hard? Because that's all it takes to work with response codes. And yes, of course parsing JSON isn't difficult. Note that I said parsing messages -- the message field not the response body. And parsing that message field and checking conditionals to determine your client's behavior is something you'll have to write code for unless y…

Two reasons why using 200 instead of 404 can make sense:

- No way to distinguish between the api client calling the wrong URL eg /mytypo/12345 instead of /myquery/12345. With 404, the client will not realise their mistake without debugging.

- Lots of 404 errors can trigger security sensors. Having to whitelist 404 in a security sensor can be a pain to convince the team that manages them. Doubly so if they are part of the other company rather than yours.

Aside from slightly less code to write, what benefit does 404 bring?

Re: API Practices If You Hate Your Customers

#155

Post by lloydatkinson »

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 experienced something similar with a currency value API. Every response was 200 OK with a field containing the actual HTTP error if there was one. I made an issue on their GitHub explaining why that made consumers code messier than it should be and asked if they could fix it. They replied saying sure, but after several months they closed the issue without a fix and then refused to reply further, and then went and did a 360 degree rebrand of the company changing the pricing model and the API itself. I ripped out usage of their garbage API and replaced it with another almost immediately.

Re: API Practices If You Hate Your Customers

#156

Post by akvadrako »

wool_gather wrote: post #75
paulddraper wrote: post #68

Earlier quoted context omitted.

For example, suppose you want to distinguish between a missing/deleted resource /myuser/23123 and a completely invalid query /muser/23123. Both of these are 404 (or 410 for permanent caching) responses according to HTTP, though they have very different reasons for "non-existance".

No, the "completely invalid query" is 400. 404 is only for "the request makes sense but that specific resource doesn't exist".

In this case it’s a 404 because the query URL pattern doesn’t exist - the most common cause of 404s.

Re: API Practices If You Hate Your Customers

#157

Post by deergomoo »

Swizec wrote: post #127
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’ve heard the argument as: “HTTP errors for protocol level errors, 200 + json for application level errors” And honestly it kinda make sense when you think about it that way. “404, wrong url” and “404, id not found” should be different errors.

> “404, wrong url” and “404, id not found” should be different errors

I'd actually argue the opposite, though I can definitely see both sides.

To me, because two systems communicating RESTfully need not know anything about each other, responding to "please give me the resource as this URI" with "there is no resource at that URI" seems perfectly correct. I don't really need to know the specifics of how the remote machine is dealing with my request.

If more detail is required you can always include a message in the request body, which I think should be standard practice for handled errors anyway.

Re: API Practices If You Hate Your Customers

#158

Post by lazyasciiart »

yardstick wrote: post #154
wwweston wrote: post #130

Earlier quoted context omitted.

While we're asking questions: what stack out there makes reading/writing HTTP headers hard? Because that's all it takes to work with response codes. And yes, of course parsing JSON isn't difficult. Note that I said parsing messages -- the message field not the response body. And parsing that message field and checking conditionals to determine your client's behavior is something you'll have to write code for unless y…

Two reasons why using 200 instead of 404 can make sense: - No way to distinguish between the api client calling the wrong URL eg /mytypo/12345 instead of /myquery/12345. With 404, the client will not realise their mistake without debugging. - Lots of 404 errors can trigger security sensors. Having to whitelist 404 in a security sensor can be a pain to convince the team that manages them. Doubly so if they are part of…

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.

Re: API Practices If You Hate Your Customers

#160

Post by wwweston »

ako wrote: post #148
akurtzhs wrote: post #5

Earlier quoted context omitted.

returning a null array to represent no items To be honest, that's what I'd expect. What do you dislike about that result, and what would you prefer to see returned? Jump straight to 404? returning a single object without an array to represent one item. So an array if there's multiple results, and a bare object for a single result? That's unpleasant.

404 indicates an error, if the result is just empty but not erroneous 204 "no content" may be better.

+1, 204 is underutilized for no-result cases.
Post reply on HN