Controllers generated with mix phx.gen.json respond with 422 status for changeset errors, whereas HTML controllers, generated with mix phx.gen.html respond with 200. I assume this is intentional, curious about the reasoning behind it. I always thought it was conventional to respond with 4xx status in the case of invalid input.
I’ve been using Unpoly, a JS library that merges HTML responses into the dom of the existing page (similar in concept to Turbolinks). Unpoly expects 4xx responses for invalid form submissions so I’ve been modifying my controllers to provide 422 responses. I’m curious why the generators don’t do this by default.
I’d argue that the status responses on the api are about the data or the operation whereas the http status on the webpage refers to the page. When a changeset error occurs while using a web UI, you’re still getting the right page, so 200 (IMO) is the right status code. If the error occurs during an api call, the error message tells you that the operation failed due to a client error (4xx), so that makes sense as well
Edit: Just a thought, I can totally see that returning the same error messages in both cases makes sense too. However, I still think that 95+ % of all web apps don‘t have a reason to return the right status code and as it can be added easily (you could even define your own generator templates), it shouldn‘t be set by default.
Thanks zimt28. Yeah I see what you mean. I’m still on the fence about which is more “correct”. Regardless, as you say, it’s trivial to change the response code to whatever works best for your situation. Thanks again.
I think 422 makes sense for web pages as well. The POST operation was in fact, invalid and the desired operation was not completed. Yes there is some HTML to look at, but there is really no semantic difference between these two cases, only a different content-type.
