Claudio B.
2013-Sep-02 17:42 UTC
Should Scaffold generate PUT/PATCH methods that respond with 200 OK (rather than 204 No Content)?
I know there is no clear consensus in the web community about this subject, so my issue is mainly to know the opinion of Rails core about this, especially @josevalim who last touched the code in 80768b<https://github.com/rails/rails/commit/80768b739ed7e2053d85a01dd5fa60bde67aad9a> . When generating a RESTful controller with `rails g scaffold`, the JSON part of the update method (responding to PUT/PATCH) looks like this: if @item.update(item_params) head :no_content else render json: @item.errors, status: :unprocessable_entity end Therefore, in order to get the whole changed object, another request must be sent to the show method (GET). Responding with :ok and an object representation might save this extra request. Citing Vinay Sahni''s Best Practices for Designing a Pragmatic RESTful API<http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#useful-post-responses> :> A PUT, POST or PATCH call may make modifications to fields of theunderlying> resource that weren''t part of the provided parameters (for example:created_at or> updated_at timestamps). To prevent an API consumer from having to hit theAPI> again for an updated representation, have the API return the updated (orcreated)> representation as part of the response.Rails *already behaves in this way* for POST (create method). Would you accept a pull request that changed the behavior of the scaffold generator to have PUT and PATCH (update method) also return the full object representation? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Brian Morearty
2013-Sep-03 02:29 UTC
Re: Should Scaffold generate PUT/PATCH methods that respond with 200 OK (rather than 204 No Content)?
I am strongly in favor of this change. I didn''t realize the scaffold was not returning the whole changed object for update, but I believe it should. For consistency with the other methods and for the convenience of the caller. As you point out, without this change the caller will have to make another HTTP round-trip when they want the complete, updated object (including any server-side side-effects that may have been applied). Brian Morearty On Monday, September 2, 2013 10:42:58 AM UTC-7, Claudio B. wrote:> > I know there is no clear consensus in the web community about this > subject, so my issue is mainly to know the opinion of Rails core about > this, especially @josevalim who last touched the code in 80768b<https://github.com/rails/rails/commit/80768b739ed7e2053d85a01dd5fa60bde67aad9a> > . > > When generating a RESTful controller with `rails g scaffold`, the JSON > part of the update method (responding to PUT/PATCH) looks like this: > > if @item.update(item_params) > head :no_content > else > render json: @item.errors, status: :unprocessable_entity > end > > Therefore, in order to get the whole changed object, another request must > be sent to the show method (GET). > > Responding with :ok and an object representation might save this extra > request. Citing Vinay Sahni''s Best Practices for Designing a Pragmatic > RESTful API<http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#useful-post-responses> > : > > > A PUT, POST or PATCH call may make modifications to fields of the > underlying > > resource that weren''t part of the provided parameters (for example: > created_at or > > updated_at timestamps). To prevent an API consumer from having to hit > the API > > again for an updated representation, have the API return the updated (or > created) > > representation as part of the response. > > Rails *already behaves in this way* for POST (create method). Would you > accept a pull request that changed the behavior of the scaffold generator > to have PUT and PATCH (update method) also return the full object > representation? > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Steve Klabnik
2013-Sep-04 17:38 UTC
Re: Re: Should Scaffold generate PUT/PATCH methods that respond with 200 OK (rather than 204 No Content)?
I feel like we had discussed this before, but am not 100% sure. I do think that this change is nice, but not mandatory. I''m neutral to mildly positive about this.
Claudio B.
2013-Sep-05 00:02 UTC
Re: Re: Should Scaffold generate PUT/PATCH methods that respond with 200 OK (rather than 204 No Content)?
Well, in case you tend more for the "mildly positive", I''ve submitted a pull request: https://github.com/rails/rails/issues/12096#issuecomment-23834726 On Wednesday, September 4, 2013 10:38:53 AM UTC-7, Steve Klabnik wrote:> > I feel like we had discussed this before, but am not 100% sure. I do > think that this change is nice, but not mandatory. I''m neutral to mildly > positive about this. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.