tags:

views:

66

answers:

3

If I am POSTing a new resource with 100 fields, and the server adds 3 fields of its own, like date created, status, etc., is it RESTful to only return a mini-representation of the resource that includes only the 3 new fields in the body of the 201 CREATED response?

Then the client can just add those 3 new fields to its local representation. I have seen exhortations that one should always send the full representation, but it seems wasteful of bandwidth to return all 103.

+1  A: 

There are no rules that claim you need to return the full response in the REST dissertation or the HTTP RFC. The latter (RFC 2616, HTTPbis version) has this to say about the 201 Created status code:

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

Returning the information that has been added is a reasonable and perfectly RESTful HTTP-compliant idea.

Stefan Tilkov
+1  A: 

It's entirely up to you what you respond with though it might be an idea to provide a link to more information about the resource. If you want to get really fancy you can specify a microformat

Chris McCauley
+1  A: 

The 201 response entity (the body of the response itself) doesn't have to be, or is considered by any http client as, the resource you just created.

It's a representation that describes the result.

If you want people to access the resource that was just created, they can do so by issuing a request to the URI in the Location header that comes back with a 201.

If you return an entity body in your 201, it is not considered by HTTP as being the resource you just created, so you can return whatever you want.

The important thing is the media type of the entity you return. If that entity is known by the client, be it that it's a smaller or the full version of the entity, they'll know what to do with it. If you expect the clietn to "know" that the returned media type to a 201 is a minimized version, you're enforcing strong coupling to your own protocol, which is in breach of ReST principles.

serialseb
Okay, so you are saying that I should define my own media type, such as application/vnd.mydomain.myapp.customer+json, and the representation returned in the body of the 201 can be a subset with just the 3 new fields?
Kevin Pauli
Absolutely. Provided you document your media type format for clients to consume, they'll know what to do with the content, together with the response. The idea being that you want ot be able to branch out your code easily so that the client knows how to handle a {customer-changes} type in whatever response it gets, and know on top of that that when it's a 201, following the Location: will let it retrieve the latest version.
serialseb
That said, be aware that for the client to know what the current state for the resource is, you will need to re-retrieve it (at least wth a HEAD), as you won't be able to deduct the new ETag or caching headers that come with it. Better to use the response to show the user what has changed, and re-retrieve the resource afresh when the user wants to do a new change.
serialseb