rails/rails — pull request #16257 by chelseatroy (2014-07-22 15:11:49+00:00)
Title: adjust api_behavior to display updated data after a patch/put request

Hi! This is not a brand new request: sometime last year a similar thing was proposed, but at the time it perhaps made sense to leave rails the way it was. I'd argue that, with some recent trends in application development, it might now be worthwhile to revisit the issue.

Namely, at the moment, an API update (PATCH/PUT request) yields :no_content. This is technically a correct approach according to Roy Fielding's HTTP Protocols (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) and as pointed out by Steve Klabnik thusly in March 2013:

"If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request."

At the moment, we see a 204 response in Rails. Again, technically correct. However, the past year and a half have heralded a rise in the use of a SOA approach to software engineering, especially in the Rails application community. Given the increase in the sheer number of APIs, the time spent editing APIs, and the instances of updates made through APIs that accompany this trend, we want to make it as convenient as possible in Rails for folks to develop, use, and read APIs—including checking their work. By changing the api_behavior method to show the updated data (200 request) after data is updated through an API, rather than a no_content (204 request), we save API users the step of manually checking the updated data in their rails console or database editor to make sure it's correct. This way, one doesn't need to use a .jbuilder view, other view, or series of code lines in their API to display updated data: the default respond_with command will just do it for them.

A note: I had the added line respond to bot PATCH and PUT, just in case, but I can also imagine why you might want it to just be PATCH at this point.