-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: V4.0_ERRATA02
-
Fix Version/s: V4.0_ERRATA03
-
Component/s: JSON Format
-
Labels:None
-
Environment:
[Applied]
-
Proposal:
In the JSON format we use annotations in the OData namespace in order to convey certain control information necessary for the client to understand the response. In the ATOM format this information was conveyed through other means (for example, using the <id> element).
So it's unclear if, or how, the odata.include-annotations preference affects the control information that happens to be conveyed through the same annotation mechanism in the JSON format, and it's relationship to the odata.metadata media type parameters.
The odata.metadata media type parameter is not very granular, and there are certainly cases where it would be nice to say "I want minimal plus type information" or "I want minimal plus navigation links", so it's tempting to say that you can additively request additional odata annotations beyond the specified metadata level. but:
1) This would be specific to format(s) that encoded the odata control information as annotations.
2) Would we ever do subtractive? Could a service request not to get ids (even if they didn't follow convention), or type information (even for derived types), or next links (even for paging)? What would client libraries or apps do, that assume absence of annotations in these cases has meaning (like the missing information follows convention, or the result is not paged).