Earlier quoted context omitted.
It is implemented as a valid HTTP code in the java Spring framework for everyone to support. That's how I learned about it first.
Same with the standard Go http package ( https://golang.org/src/net/http/status.go?s=2540:2600 ).
Reserve the 418 status code
61–70 of 124 posts
Re: Reserve the 418 status code
#62Many 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…
Why do you think that?
An application-level failure is a "server problem". It's possible there is nothing between the OS handling TCP and your application.
This is also against the concept of REST and traditional HTTP servers, which do use HTTP error codes.
Re: Reserve the 418 status code
#63Many 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…
I disagree. HTTP is a widely known standard with a ready to use client/server implementation in basically any platform. Leveraging that semantically in API seems to improve productivity all around. Are there any major trade offs?
The alternative is making standards for how to format the payload and try to get everyone on board while also trying to manage another half a dozen or more legacy implementations of non-standards. Or don't make standards and live with the fact that every API will do its own thing and you have to handle everything differently each time you have to talk to anyone.
As a practical example, I would really prefer not to have to parse a XML response to get a status code in my js frontend, nor would I'd like to examine it via string/regex matching.
Re: Reserve the 418 status code
#64Many 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…
While I'm inclined to agree with you the makers of SOAP don't seem to share your opinion. Any SOAP fault must be send with an HTTP 500 according to the spec.
My take on SOAP's approach is that it isn't overloading HTTP status messages, it's attempting to impose SOAP's message structure on things that are legitimately HTTP 5xx responses, so that the soap client can handle some of those failure modes and the programmer doesn't have to engineer another protocol for dealing with transport errors or parse a different message format.
Notably, SOAP is not just doing REST it is attempting to offer an abstraction for dealing with transport issues.
Most people designing a REST or rpc style API do not attempt this breadth in their API design, instead they just overload HTTP response codes (from the HTTP and webDAV specs) to handle application-specific stuff, which ends up resulting in the codes being effectively meaningless across applications.
SOAP, on the other hand, is meant to be used in the same way across applications. So if your app uses SOAP to consume multiple SOAP APIs, and you engineer failure handling for the HTTP 500 associated with some kind of SOAP fault, chances are you can reuse this logic with all of the SOAP APIs.
On the contrary, many REST APIs that overload HTTP statuses do it in some arbitrary way defined by the team working on the API, so the consumer can't make generalizations about the meaning of the error codes in the common cases where one might determine (for example) a retry to be necessary.
Re: Reserve the 418 status code
#65Earlier quoted context omitted.
While I'm inclined to agree with you the makers of SOAP don't seem to share your opinion. Any SOAP fault must be send with an HTTP 500 according to the spec.
My take on SOAP's approach is that it isn't overloading HTTP status messages, it's attempting to impose SOAP's message structure on things that are legitimately HTTP 5xx responses, so that the soap client can handle some of those failure modes and the programmer doesn't have to engineer another protocol for dealing with transport errors or parse a different message format. Notably, SOAP is not just doing REST it is a…
> Most people designing a REST or rpc style API do not attempt this breadth in their API design, instead they just overload HTTP response codes (from the HTTP and webDAV specs) to handle application-specific stuff, which ends up resulting in the codes being effectively meaningless across applications.
HTTP status codes exist to be overloaded, especially in the 4xx range. As per the IETF: https://tools.ietf.org/html/rfc7231#section-6.5
Re: Reserve the 418 status code
#66Yeah, I'm sorry, but now we need to standardize BREW HTTP verb.
Re: Reserve the 418 status code
#67Many 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…
Why do you think that? An application-level failure is a "server problem". It's possible there is nothing between the OS handling TCP and your application. This is also against the concept of REST and traditional HTTP servers, which do use HTTP error codes.
> It's possible there is nothing between the OS handling TCP and your application.
This does happen, and it results in the client having to have ad-hoc code to deal with a nearly infinite number of possible "Server error" scenarios, some of which may be normal functions of the API and others which may actually be server failures.
> It's possible there is nothing between the OS handling TCP and your application.
I'm not arguing that one shouldn't use HTTP status codes, I'm arguing that they should be used only for the standard meaning of the code, one should not need to consult a table provided by the API designer to determine which 4xx HTTP status codes warrant a retry, and which 5xx status codes are normal vs exceptional situations.
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 (suppose your app doesn't allow usernames that are profane words, for example). The response should not be 5xx, it should be 2xx with a message indicating the application's preferred range of values. 5xx means that something went wrong on the server trying to fulfill the request, 2xx means that the request was fulfilled properly, and any additional info relevant to the client should be passed along as part of that 200 response.
> This is also against the concept of REST
Very few APIs can be designed well as 100% REST. Lots of very typical scenarios necessitate jumping through a lot of hoops to use REST in a pure way. REST fights with database normalization in some cases and with many authentication scenarios. It can also require the client to maintain a fairly elaborate (and brittle) representation of server-side state that is mostly unnecessary.
REST makes sense when there is a perfect alignment between REST verbs and data flows, but when you get into a situation where it's necessary to make multiple API calls to do one logical operation, it would probably have been simpler not to use REST in the first place and to have just designed a simple, clean, non-REST API.
Re: Reserve the 418 status code
#68I actually use the 418 code in a simple API we use for IOT devices. I wrote a small program that runs on Raspberry Pis that checks a HTTP endpoint and turns power on and off to a room depending on whether the room is booked out. I wanted a status code on the API that could only possibly be generated on purpose, so if it receives a 418 response it knows to turn off the power; any other response, failure etc turns the…
I was hoping for a minute that the IOT device was a connected teapot...
I solved this with a WeMo plug, which gives me an app and alexa control. Used for electric hair iron of wife, and coffee pot as backup plan with timeout setting, and also saving us driving back home for the "did you unplug the iron" moments.
Both appliances actually have their own auto-off, but I like redundancy.
Re: Reserve the 418 status code
#69Many 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.
Re: Reserve the 418 status code
#70Earlier quoted context omitted.
My take on SOAP's approach is that it isn't overloading HTTP status messages, it's attempting to impose SOAP's message structure on things that are legitimately HTTP 5xx responses, so that the soap client can handle some of those failure modes and the programmer doesn't have to engineer another protocol for dealing with transport errors or parse a different message format. Notably, SOAP is not just doing REST it is a…
> Most people designing a REST or rpc style API do not attempt this breadth in their API design, instead they just overload HTTP response codes (from the HTTP and webDAV specs) to handle application-specific stuff, which ends up resulting in the codes being effectively meaningless across applications. HTTP status codes exist to be overloaded, especially in the 4xx range. As per the IETF: https://tools.ietf.org/html/r…
> HTTP status codes exist to be overloaded
If you look at most of the status codes they pertain to the transport itself: content negotiation, content size, etc.
In other words, the client would be pleased to see one of those codes when making a request and wondering "Why is this not returning the data I expect?".
Compare this to a typical scenario in an application of signing up a user. If the user types in a password that does not meet the password complexity requirements or chooses a username that is already taken, there was not a problem with the transport mechanism, there is an application-specific constraint that the programmer calling the API did expect to encounter some of the time, because of course both of these are common scenarios.
If for some reason the application code does not limit usernames to a small number of characters and the API returns an HTTP 413 status, that is unexpected to the programmer, so the non-200 code is appropriate. The programmer needs to rethink the transport assumptions assuming that super long usernames are OK.
The distinction is that HTTP errors apply to HTTP itself. Are the basic requests and responses functioning properly, etc. But application-specific things generally belong in a separate layer of metadata.
I've seen some very very bad API designs that totally misuse HTTP status codes, largely influenced by the old jQuery pattern of a success and failure callback, with 2xx triggering the success callback and 4xx and 5xx triggering the failure callback. How many times has some server error resulted in confusion because the error callback is being used to handle routine flow control in the application code.