You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's very useful to be able to distinguish capabilities of a single entity in a collection vs the capabilities of a collection.
This is embodied in ReadRestrictions vs ReadByKeyRestrictions for support for GET foos vs GET foos/{fooId}
In practice we've found that implementing $expand on a single entity is frequently cost-effective, whereas implementing it across a whole collection is not. Consequently we'd like to be able to qualify ExpandRestrictions with something akin to an ExpandByKeyRestrictions.
A cheap and cheerful variant of this would be a boolean control flag in ExpandRestrictions, but it misses the possibility that the expandable set of nav properties varies between single/collection.
For clarity, we need a vocabulary annotation that allows us to express
NOT Supported: GET /foos?$expand=bars
Supported: {{GET /foos/{fooId}?$expand=bars}}
Another issue of ExpandRestrictions is ODATA-1502.
Gareth Jones opened [https://github.com/oasis-tcs/odata/issues/12:]
It's very useful to be able to distinguish capabilities of a single entity in a collection vs the capabilities of a collection.
This is embodied in ReadRestrictions vs ReadByKeyRestrictions for support for GET foos vs GET foos/{fooId}
In practice we've found that implementing $expand on a single entity is frequently cost-effective, whereas implementing it across a whole collection is not. Consequently we'd like to be able to qualify ExpandRestrictions with something akin to an ExpandByKeyRestrictions.
A cheap and cheerful variant of this would be a boolean control flag in ExpandRestrictions, but it misses the possibility that the expandable set of nav properties varies between single/collection.
For clarity, we need a vocabulary annotation that allows us to express
GET /foos?$expand=bars
Another issue of ExpandRestrictions is ODATA-1502.
Imported from ODATA-1639
The text was updated successfully, but these errors were encountered: