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

Handle "data" wrappers #24

Open
Nikkelmann opened this issue Nov 8, 2018 · 3 comments
Open

Handle "data" wrappers #24

Nikkelmann opened this issue Nov 8, 2018 · 3 comments

Comments

@Nikkelmann
Copy link

According to https://developers.google.com/drive/api/v3/performance#partial requests to API responses that use "data" wrappers, where the response is nested within a data object that looks like data: { ... }, one should not include "data" in the fields specification.

So instead of "fields=data(a,b)" it should be specified like "fields=a,b".

In this case the filtering is only applied to the data property; any other properties of the wrapper object should not be filtered. Eg. { "success": true, "data": { ... } }

To not break the old versions this could be implemented as a property like with IgnoreCase on PartialJsonMediaTypeFormatter.

@dotarj
Copy link
Owner

dotarj commented Dec 24, 2018

Sorry for the delay, this project hasn’t had the focus it should have had. The documentation isn’t very explicit on the data field, but if I understand correctly, the data field is always in the first level of the JSON response, eg.:

{
“success”: true,
“data”: {
...
}
}

And filtering fields only affects fields in the data field, so other fields (success in this example) can’t be filtered (of course, only if the option is enabled).

Please let me know if you agree on this. I will think of a solution for this and get back to you. Suggestions are welcome!

@Nikkelmann
Copy link
Author

Agreed.

@zihotki
Copy link

zihotki commented Dec 27, 2018

From my experience the data is always either on root level (without wrapper) or on 1st level (data field or alternative). I never saw any other options so I also agree that it's safe to assume it.

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

No branches or pull requests

3 participants