Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reserve the 418 status code

tools.ietf.org

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Reserve the 418 status code

#91

Post by vfaronov »

grandalf wrote: post #90
vfaronov wrote: post #87

Earlier quoted context omitted.

Here’s the standard for 422: https://tools.ietf.org/html/rfc4918#section-11.2 . It’s not a WebDAV-specific error condition. People are right to see the similarity and reuse the status code. This is not “overloading”.

There will be cases where an HTTP status code matches perfectly with an application specific scenario, and in those cases using an HTTP status code is not confusing. The confusion comes when the API developer tries to shoehorn all application specific errors into pre-existing HTTP status codes. In most cases it is clearer to simply adopt a payload format that includes application specific error codes, so that the cla…

> In most cases it is clearer to simply adopt a payload format that includes application specific error codes

Absolutely. This is a common practice and there’s even a proposed standard for it (RFC 7807). But such a payload need not be sent with 200 (OK). It can refine the status code instead of overriding it.

Re: Reserve the 418 status code

#92

Post by nulagrithom »

grandalf wrote: post #74
marrs wrote: post #69

Earlier quoted context omitted.

Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. You mean like a form validation error? Surely an invalid request is a bad request. No?

> Surely an invalid request is a bad request. Invalid to whom? Should a form submitted with a username that already exists in the system get a 500 response code? What's the server error?

I'd go with 409 Conflict, but I'd also accept 400 Bad Request

Incidentally, the RFC for 409 makes it quite clear that this touches the application layer:

> Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.

https://tools.ietf.org/html/rfc7231#section-6.5.8

In any case, getting pedantic about what's "an error" and using 200 OK for everything that didn't fail at the transport layer is a super frustrating experience regardless of whether or not it's semantically correct. Please don't do that to consumers of your API.

Re: Reserve the 418 status code

#93

Post by krisdol »

grandalf wrote: post #75
akvadrako wrote: post #72

Earlier quoted context omitted.

> Suppose you make a call to an API and it returns 5xx because you provided a parameter value that is valid in the URL or payload but invalid in the app That is wrong. Client mistakes should get 400-level error codes. A 200-level code indicates the request completed successfully, which it didn't. There is no difference between an "HTTP server" and an app. They are often the same thing, like when using Apache to serve…

> Don't return a 200 code when the request failed. The request didn't fail, it simply followed application logic and returned a successful response indicating the nature of the application logic to the client. That is not an error condition, it's just application logic.

So then if my application logic catches a thrown exception because I don't want my app to crash every time a server bug is exposed, I should be returning a 200 OK response rather than a 500 Internal Server Error, because the app logic accounts for handling exceptions and returns a response.

I can't disagree more. It just seems like clients would have a nightmare of a time debugging client-side code against such a system.

Re: Reserve the 418 status code

#94

Post by caseysoftware »

grandalf wrote: post #54

Many API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response. Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. HTTP is the transport layer, and a…

No.

You should never, ever, ever return a 2xx status code with an error payload. The 2xx series means "Success" and you're abusing HTTP to use it to mean anything else.

With regard to application layer vs transport layer, the 404 Not Found, 406 Not Acceptable, 409 Conflict, and many others errors are specifically application layer codes. If you can't get a more specific code, 400 Bad Request with an expressive payload is useful. The 500 codes are generally transport layer.

The reason that APIs are getting easier and easier to understand and use is because we're using the same design patterns consistently and repeatedly. Therefore, the understanding you gain from the Twilio API can be applied to Stripe. If you use existing tools in new and "innovative" ways that are contrary to - instead of in addition to - to their intention, you're setting back adoption and making your users re-figure out basic things. Don't.

Or worse, people don't realize how you're misusing the tools and build flawed systems.

(The one exception I'd give you is 202 Accepted which is generally used for "we've accepted this for now but processing and final validation may occur later" - it's a tentative success message.)

Re: Reserve the 418 status code

#95

Post by moocowtruck »

marrs wrote: post #69
grandalf wrote: post #54

Many API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response. Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. HTTP is the transport layer, and a…

Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. You mean like a form validation error? Surely an invalid request is a bad request. No?

agreed... especially because it is an error and if i return a 2xx then the frontend code will then have error logic in the success logic why have two checks when i can have one..

Re: Reserve the 418 status code

#96

Post by [deleted] »

marrs wrote: post #69
grandalf wrote: post #54

Many API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response. Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. HTTP is the transport layer, and a…

Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. You mean like a form validation error? Surely an invalid request is a bad request. No?

[deleted]

Re: Reserve the 418 status code

#97

Post by dragonwriter »

grandalf wrote: post #54

Many API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response. Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. HTTP is the transport layer, and a…

> HTTP is the transport layer

No, HTTP is the application layer. TCP is the transport layer.

> and any application specific scenarios are best handled with a custom error namespace that can be returned within any 2xx HTTP response.

No, generally application errors should be 4xx or 5xx codes; greater detail can be provided in the payload, sure, but a proper error condition should be returned, 4xx for errors resulting from the client request being unacceptable in some way, 5xx for other errors (which are, necessarily, server errors.)

(If you are tunneling another application-layer protocol over HTTP, your argument makes sense, but that's not the general case with APIs.)

Re: Reserve the 418 status code

#98

Post by [deleted] »

grandalf wrote: post #54

Many API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response. Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. HTTP is the transport layer, and a…

[deleted]

Re: Reserve the 418 status code

#99

Post by grandalf »

myusernameisok wrote: post #88
grandalf wrote: post #74

Earlier quoted context omitted.

> Surely an invalid request is a bad request. Invalid to whom? Should a form submitted with a username that already exists in the system get a 500 response code? What's the server error?

Some APIs I've seen just use 400 for all generic client-side errors, including request syntax errors, impossible requests, duplicate requests, etc. I would argue that most of the time, for any sufficiently large application, you'll need to use application specific status codes anyway (as you said), so why bother trying to be specific with the HTTP error codes? Certain client-side applications parse out if the respons…

Exactly.

Re: Reserve the 418 status code

#100

Post by eric_b »

caseysoftware wrote: post #94
grandalf wrote: post #54

Many API developers misuse/overload HTTP status codes when they should actually be using application specific status codes delivered via a wrapper to the response. Any time an API returns a correct response the HTTP response code should be 2xx. Many developers use 4xx status codes to indicate things like data validation errors or other things that are not part of the HTTP transport. HTTP is the transport layer, and a…

No. You should never, ever, ever return a 2xx status code with an error payload. The 2xx series means "Success" and you're abusing HTTP to use it to mean anything else. With regard to application layer vs transport layer, the 404 Not Found, 406 Not Acceptable, 409 Conflict, and many others errors are specifically application layer codes. If you can't get a more specific code, 400 Bad Request with an expressive payloa…

Uh what? If the request was appropriately formatted, not too large, and generally acceptable to the server from a transport perspective, why shouldn't it succeed with a 200?

Error handling is an application level concern, not a transport level concern.

HTTP status codes lack the nuance required to inform the end user about errors in any non-trivial application. I personally enjoy the OP's solution. I've worked on dozens of REST APIs in my life, and I always prefer those that contain a response envelope complete with metadata and error responses.

Pre-emptive edit: When I say error handling is an application level concern, I don't mean "application" from an OSI model perspective, which is narrower in scope than what I'm talking about.

Post reply on HN