PUT request, respond_with and the json rendered content

rubyonrails-core
1

Since this commit : Return a valid empty JSON on successful PUT and DELETE requests. [#51… · rails/rails@0d33332 · GitHub

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.

2

-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
3

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.

4

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.)

5

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.

6

Agree.

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

Thanks for your answers!