71–80 of 124 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 n…
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 files from disk.
> 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
Of course you should use the error codes correctly! Don't return a 200 code when the request failed.
Earlier quoted context omitted.
You never know. Some people used to think 4 billion slots would be more than enough for addressing every host in the world, and so they allocated the addresses haphazardly. Now look at the sorry state of IPv6 adoption 20 years after it's been designed. Some people used to think 65536 code points would be more than enough to encode every character in every language. Later it turned out not to be the case. Expanding th…
As frivolous as you think 418 is, people use it. You honestly can't, in this situation, be the judge of what is "frivolous use" and what is not.
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?
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?
Earlier quoted context omitted.
> 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 n…
> 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…
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.
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?
Earlier quoted context omitted.
You never know. Some people used to think 4 billion slots would be more than enough for addressing every host in the world, and so they allocated the addresses haphazardly. Now look at the sorry state of IPv6 adoption 20 years after it's been designed. Some people used to think 65536 code points would be more than enough to encode every character in every language. Later it turned out not to be the case. Expanding th…
As frivolous as you think 418 is, people use it. You honestly can't, in this situation, be the judge of what is "frivolous use" and what is not.
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…
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-stan…
Yes, see my other comments in this thread.
Earlier quoted context omitted.
> 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 passwor…
There are no unexpected status codes if your API is fully documented. I gave a short talk about this last year: https://www.youtube.com/watch?v=9w4dNi2wu_E&feature=youtu.be...
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?
You could use 422.
A big portion of the improper overloading of HTTP status codes comes from WebDAV status codes seeming appealing when in fact WebDAV is a very specific set of functionality that is not really analogous to the way most REST APIs work... notably WebDAV offers locking semantics.