0

To be most compatible with practice RESTful service development and existing Javascript MVC frameworks like AngularJS and Ember.js that would be used to integrate with a RESTful service, should a resource be deserialized to JSON from a RESTful PUT call that just updates a resource?

For example, Rails 3.2.8 seems to promote just using respond_with @foobar.update_attributes(...) which just returns an HTTP status code 204. However, you can specify that you want respond_with or respond_to to return the resource.

But, this means that another call must be made to get the resource to get any updates that may have occurred on the resource in addition to the ones that were specified in the PUT call. On one hand it is nice not to have anything returned, because you may not care if it has changed, and this isn't like POST in which you are creating a new resource and may want a full representation with the new id. However, having to make another GET call to get the updated resource following the PUT, though nice that it is intentional, is additional overhead (i.e. for a PUT where you need the updated resource, you would have to PUT and then GET).

I understand that REST leaves a lot open as to implementation, but I'd like to understand what people agree is a good practice with regard to this, at least as of October 2012 in the stated context of being used by AngularJS and Ember.js, and why.

Gary S. Weaver
  • 7,966
  • 4
  • 37
  • 61
  • What size of entities are we talking? – Donal Fellows Oct 09 '12 at 21:39
  • Good question! Not so large that it would be impractical to send in a single request (i.e. we're not currently planning on doing large uploads in a RESTful PUT). – Gary S. Weaver Oct 10 '12 at 22:18
  • Answer to related question: http://stackoverflow.com/a/11131630/178651 – Gary S. Weaver Oct 10 '12 at 22:22
  • Even though it may not follow everyone's understanding of REST nor Rails tradition thus far, there is an answer here that will help you return the resource on both a post with a 201 and put with a 200 by using a custom responder. We've found this to be helpful: http://stackoverflow.com/questions/9953887/simple-respond-with-in-rails-that-avoids-204-from-put/10087240#10087240 – Gary S. Weaver Oct 29 '12 at 20:43
  • As an update, we stopped using the custom responder mentioned in the other question because it was problematic and touchy to changes. Now in the update, we do a find, update_attributes, and where the resulting model instance is @value we do: `respond_with(@value) do |format|; format.json do; if @value.errors.empty?; render json: @value, status: :ok; else; render json: {errors: @value.errors}, status: :unprocessable_entity; end; end; end` and, for the create, it is the same except instead of :ok, we use :created. – Gary S. Weaver Nov 30 '12 at 22:54

0 Answers0