Change return codes to new Responders defaults

[tagliala]

Change default error and redirect status codes Update responder class to the current defaults for responder gem

Close: https://github.com/activeadmin/inherited_resources/issues/862

Ref: https://github.com/heartcombo/responders/pull/240

Supersedes #863

---

I'm doing some tests with this branch and $ bin/rake local server with Active Admin main

Action	Method	Status Before	Status After	Match Rails
Create category	POST	302 Found	303 See Other	❌ (302, but 303 is better)
Create category (fail validations)	POST	200 OK	422 Unprocessable Entity	✅
Update category	POST	302 Found	303 See Other	❌ (302, but 303 is better)
Update category (fail validations)	POST	200 OK	422 Unprocessable Entity	✅
Destroy category	POST	302 Found	303 See Other	✅

Rails by default returns 302 on successful create and update, and 303 only on destroy. However, according to HTTP/1.1 standard, it appears that 303 is the correct status code to redirect from a POST/PATCH/PUT/DELETE to a GET and clients do treat 302 like a 303, by using GET instead of using the original method

References that motivate the decision:

• rails/rails#45393

• hotwired/turbo#84

• https://github.com/heartcombo/responders?tab=readme-ov-file#configuring-error-and-redirect-statuses

  Note: the application responder generated for new apps already configures a different set of defaults: 422 Unprocessable Entity for errors, and 303 See Other for redirects. Responders may change the defaults to match these in a future major release.

• https://en.wikipedia.org/wiki/HTTP_302

  Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g. POST).[1] For this reason, HTTP/1.1 (RFC 2616) added the new status codes 303 and 307 to disambiguate between the two behaviours, with 303 mandating the change of request type to GET, and 307 preserving the request type as originally sent. Despite the greater clarity provided by this disambiguation, the 302 code is still employed in web frameworks to preserve compatibility with browsers that do not implement the HTTP/1.1 specification.[2]

  (emphasis mine)

• https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.4

  If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

  (emphasis mine)

Default responder created by rails g responders:install: https://github.com/heartcombo/responders/blob/9bdc60dfbfa8001641c1c4df7bc73c3fc2a4cf41/lib/generators/responders/install_generator.rb#L10-L25