You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It occurs to me a Responder should rarely ever convert an error status returned from a Domain object into an HTTP 400 status code. Presently, the model code does do this:
Status 400 means a Bad Request was made by the client, most likely a web browser. If that were the case, such an error should be caught on input, most likely before any real application domain code is even executed. I can imagine a situation where one might have an Action class that checks client input in such a way that it might need to generate a Bad Request 400 response. But I think that's a fairly unusual case. As a writer on Stack Overflow put it:
Using 400 status codes for any other purpose than indicating that the request is malformed is just plain wrong.
Instead, status 500 is probably what is wanted in most cases where a Domain class returns some kind of error. Quoting the spec:
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.
The text was updated successfully, but these errors were encountered:
I think maybe the notional mapping of the Aura\Payload_Interface\PayloadStatus values, which are distinct to domain objects, into HTTP status codes in Radar\Adr\Responder in method getMethodForPayload() is flawed. A Domain object could intelligently return a value of FAILURE that indicated some condition which only the Domain considers a failure, but which from the HTTP Responder's point of view is expected. At a minimum, it would almost certainly not be the result of a malformed HTTP request. Yet, present code maps this Domain status into HTTP 400, which means exactly that (malformed). It seems like there needs to be more sophistication in this mapping, and probably it will be somewhat application dependent.
In my final* design, I ended up mapping almost everything to HTTP 200 and instead using Responder classes and templates to display useful error messages to users.
For your consideration:
It occurs to me a Responder should rarely ever convert an error status returned from a Domain object into an HTTP 400 status code. Presently, the model code does do this:
Status 400 means a Bad Request was made by the client, most likely a web browser. If that were the case, such an error should be caught on input, most likely before any real application domain code is even executed. I can imagine a situation where one might have an Action class that checks client input in such a way that it might need to generate a Bad Request 400 response. But I think that's a fairly unusual case. As a writer on Stack Overflow put it:
Instead, status 500 is probably what is wanted in most cases where a Domain class returns some kind of error. Quoting the spec:
The text was updated successfully, but these errors were encountered: