Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GET for Collection endpoints vs Document endpoints return inconsistent Item content #29

Closed
hluz opened this issue Apr 4, 2013 · 5 comments

Comments

@hluz
Copy link

hluz commented Apr 4, 2013

  • Individual items returned from a GET on a Collection endpoint do not include "parent" and "collection" links. For consistency with a GET on Document, it should.
  • Item returned from a GET on a Document endpoint does not include "etag" value. Although an Etag header is included in the response, for consistency with a GET on Collection, it should also be included in the Content item.
@nicolaiarocci
Copy link
Member

Hello and thank you for your comments. Both are actually design decisions taken to minimize payload size, which is an important factor when dealing with possibly unpredictable connections (think mobile).

If you're on a collection endpoint, by definition you already know the documents parent (you're on it). Besides, that piece of information is actually in the payload already (the "self" link in _items). Repeating that link for every document in the payload seems like an optimization waste. Consider that there could be hundreds (or even thousands) duplicates in case the API maintainer, for some obscure reason, decides to turn pagination off.

For the same reason the etag is not duplicated at the item endpoint. It's in the header already, you don't probably need that piece of information twice within the same payload. At collection endpoint we're forced to serve individual etags since we want to allow for subsequent direct conditional requests (If-Match) on individual documents, without forcing a previous document lookup. For coherence however, it would probably be reasonable to add the etag in the json/xml stream too, as in this case the 'waste' would be pretty much insignificant. Let's see what/if others have something to say on this point.

@hluz
Copy link
Author

hluz commented Apr 5, 2013

Nicola, I understand and see the validity of your point about minimising payload size, and about the duplicated data inside the payload. For the etag though, as you mention, it would make sense to be in the payload (as well the HTTP header). In other words, forget about point 1 and keep point 2.

@hluz hluz closed this as completed Apr 5, 2013
@hluz hluz reopened this Apr 5, 2013
@nicolaiarocci
Copy link
Member

What if this 'choerence mode' is disabled by default but you can switch it on with a global setting, something like a COHERENCE_MODE boolean?

@hluz
Copy link
Author

hluz commented Apr 7, 2013

That would totally do it, of course ;-)

@nicolaiarocci
Copy link
Member

Screw the COHERENCE_MODE we'll just throw the ETag in the payload instead. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants