PUT request, respond_with and the json rendered content

1,204 views
Skip to first unread message

Damien MATHIEU

unread,
Oct 19, 2011, 3:04:26 AM10/19/11
to rubyonra...@googlegroups.com
Since this commit : https://github.com/rails/rails/commit/0d3333257156544feba729ba28f6874d5a30d561
PUT requests made on a controller using respond_with with the format json render an empty hash.
José explains in the comments why it does so and it doesn't just renders the modified document, like we do in POST.

I would like to propose changing that default though, in the respond_with and the scaffold to respond the modified object instead of an empty hash.

Prem Sichanugrist

unread,
Oct 19, 2011, 10:27:14 AM10/19/11
to rubyonra...@googlegroups.com
-1

PUT does not need to return the object because client would already know the object's attribute. If the client wants to refresh the object, they should issue another GET request.

POST returns the newly created object so that the client can cache the object with all of the attributes and id.

Also, I think changing this would break all applications. If someone supporting this, it should go to Rails 4.0, not 3.2.

- Prem

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/u60P7OSRIh8J.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Damien MATHIEU

unread,
Oct 19, 2011, 10:45:18 AM10/19/11
to rubyonra...@googlegroups.com
On a PUT request, the client does not always know the object's attributes. One calculated attribute is enough so you don't know it.
You might need to update the value of updated_at for example.

Jeremy Kemper

unread,
Oct 19, 2011, 10:48:56 AM10/19/11
to rubyonra...@googlegroups.com
PUT should respond with 204 No Content, rather than 200 OK, and omit the body.

(Since it's responding with 200 OK today, including a JSON body makes sense, but an empty JSON object doesn't make sense to me.)

Prem Sichanugrist

unread,
Oct 19, 2011, 10:50:45 AM10/19/11
to rubyonra...@googlegroups.com
Hmm I see your point now. But yeah, I don't know that how much impact it would make to people's application after the change.

Dmitry Polushkin

unread,
Nov 8, 2011, 11:31:56 AM11/8/11
to Ruby on Rails: Core
Agree.

Is it possible to have non empty rendered hash, without writing own
responder class?

Thanks for your answers!

On Oct 19, 2:45 pm, Damien MATHIEU <4...@dmathieu.com> wrote:
> On a PUT request, the client does not always know the object's attributes.
> One calculated attribute is enough so you don't know it.
> You might need to update the value of updated_at for example.
>
> On 19 October 2011 16:27, Prem Sichanugrist <sikand...@gmail.com> wrote:
>
>
>
>
>
>
>
> > -1
>
> > PUT does not need to return the object because client would already know
> > the object's attribute. If the client wants to refresh the object, they
> > should issue another GET request.
>
> > POST returns the newly created object so that the client can cache the
> > object with all of the attributes and id.
>
> > Also, I think changing this would break all applications. If someone
> > supporting this, it should go to Rails 4.0, not 3.2.
>
> > - Prem
>
> > On Oct 19, 2011, at 3:04 AM, Damien MATHIEU wrote:
>
> > Since this commit :
> >https://github.com/rails/rails/commit/0d3333257156544feba729ba28f6874...
Reply all
Reply to author
Forward
0 new messages