Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
that_james
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
4 ms
·
1.
▲
by
that_james
4y ago
Posting another comment rather than updating my last one: Thanks to all for the feedback. After knocking it around in my head, I concede I am wrong :) HTTP is, after all, an Application layer protocol. Whilst I remain unconvinced by some of
2.
▲
by
that_james
4y ago
That was what I meant by "actual web servers" :D poorly described though, fair enough. I should have been clearer about this relating to HTTP RPC. I updated the post. That said, after reading the responses here, I can see that wha
3.
▲
by
that_james
4y ago
I even put 500 in the post :) I was hoping to start a discussion around using HTTP status codes as domain error codes, as opposed to an opinionated payload. Maybe not as clear as I could have made it.
4.
▲
by
that_james
4y ago
That's not the takeway I was after, I was pretty certain I had clearly described my intention of debating the usage of HTTP status codes as domain error messages. Not really sure why you think I'm of the opinion only 2xx codes can
5.
▲
by
that_james
4y ago
> People rarely assume there’s an API contract in error messages But then what's the point of an API contract if it's not describing the returned data? What I'm arguing is the opinionated payload provides a lot of the same
6.
▲
by
that_james
4y ago
> Thus -- as REST is /the/ canonical "hijack HTTP status codes to mean something clever" paradigm -- your article is /entirely/ in context of REST. Oof, that's a hell of a good point. So much for that p
7.
▲
by
that_james
4y ago
Y'all have given me a lot to chew on. I would like to point out a few of the detractors are conflating REST and HTTP RPC, I avoided using the term REST for a reason :) BUT, that being said, lots of good arguments against this stance. I
8.
▲
by
that_james
4y ago
REST is not HTTP! I didn't mention REST for a reason :) But that's a good point about the transport layer.
9.
▲
by
that_james
4y ago
For me it boils down to this: If you ask for an employee that doesn't exist, is it a failure? Or is it just a negative, but expected response? Perhaps that's a stupid question though.
10.
▲
by
that_james
4y ago
That's a succinct definition, happy to admit that's a better argument than mine
11.
▲
by
that_james
4y ago
> when my systems are sending out a ton of 422s or 400s that's a useful signal to me that something is going on Why not ping the monitoring when you encounter the business error? From that perspective, a stream of HTTP errors could
12.
▲
by
that_james
4y ago
I appreciate the kind words, thank you. I've said it in other responses, but maybe I should have been specific that I was referring to HTTP RPC (explicitly not citing REST for a reason). Perhaps a combination of both is best, but in my
13.
▲
by
that_james
4y ago
I think the issue is here is that I should have explicitly stated this was about HTTP RPC (I am steering clear of REST for a reason). In the context of RPC, is it still impractical? It feels clearer to me, but I might just be continuing my
14.
▲
by
that_james
4y ago
Ah, you got me on that one, fair point. But then it would be both, wouldn't it? I know I have a JSON payload representing a domain response because of the 2xx response code AND the Content-Type header?
15.
▲
by
that_james
4y ago
I very intentionally avoided the REST vs HTTP RPC debate. This is _specifically_ about HTTP APIs. REST is not a synonym for HTTP but there are much better resources out there that rant on about the important of hypertext and URL support etc
16.
▲
by
that_james
4y ago
Sho, I don't know. Maybe? I've never seen one in the wild, but looking at the docs is that error not reserved for using the wrong protocol (such as 1/1 when the server only accepts 2 or something?)
17.
▲
by
that_james
4y ago
That's a very good point. It's also why I raised the issue of where your "server boundary" is. I dunno how else to phrase it, but what I mean is the separation of domain logic and technical logic. In my understanding, 40
18.
▲
by
that_james
4y ago
I don't think there's a correct answer, this is just an opinion I stumbled into this morning. The objective mostly was to try help form a way of reasoning about HTTP APIs from the consumer's perspective > error 400 for all
19.
▲
I've been abusing HTTP Status Codes in my APIs for years
(blog.slimjim.xyz)
206 points
by
that_james
4y ago
|
322 comments