brucepomeroy
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.
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
zimt28
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 wellEdit: 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.
brucepomeroy
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.
jeremyjh
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.