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

Add version property to ResponseBody if the returned response is of collection type [DATAREST-636] #1013

Closed
spring-projects-issues opened this issue Aug 6, 2015 · 1 comment
Assignees
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link

Rakesh opened DATAREST-636 and commented

Currently, the version property is being stripped of from payload through PersistentEntityJackson2Module. The ETag support is available when individual entities are pulled. But, obviously it doesn't make sense for a collection (A collection of search results for example). Now, when the client intends to update an entity from a search result, it is counter productive to make a server call just to know the ETag of that entity.

In such a case, providing support for adding version number in the payload could be of some help.


Reference URL: http://stackoverflow.com/questions/31843179/jackson-jpa-version-not-serialized/31855381

@spring-projects-issues
Copy link
Author

Oliver Drotbohm commented

The HTTP specification for If-None-Match and If-Match states:

A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field.

As you can see this includes both "previously obtained" and "entity tags". Hence, to use this functionality an ETag has to be obtained. You can use a HEAD request
to obtain the ETag for an item resource to save bandwidth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants