[OASIS Issue Tracker] (ODATA-1018) Allow $expand and $select with modifying requests that return a collection in combination with return=representation to specify the response shape

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/ODATA-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-1018:
------------------------------

    Environment: Proposed
       Proposal: 
Extend allowing use of $select and $epand to requests that return a collection
1) if $expand/$select are present, implies return=representation
2) if $expand/$select are present and return=minimal, service MUST include preference-applied if they DON'T return a result
3) if it returns a result, $expand MUST be applied if specified and MUST include at least the $selected columns
4) the service MUST NOT fail the request due to the $expand/$select; if the service cannot return a result with the appropriate $expand and $select it MUST return No Content

Revisit ODATA-615 and resolve it with a /$filter(...) path segment as proposed in ODATA-836:

DELETE Products/$filter(Age gt 3)
PATCH Products/$filter(@f)?@f=Age gt 2


  was:
Extend allowing use of $select and $epand to requests that return a collection
1) if $expand/$select are present, implies return=representation
2) if $expand/$select are present and return=minimal, service MUST include preference-applied if they DON'T return a result
3) if it returns a result, $expand MUST be applied if specified and MUST include at least the $selected columns
4) the service MUST NOT fail the request due to the $expand/$select; if the service cannot return a result with the appropriate $expand and $select it MUST return No Content



It is weird that $filter is sometimes is applied before the operation - ODATA-615 - and in most cases after the operation to shape the result.

How about revisiting ODATA-615 and re-resolving it along the lines of ODATA-836 by introducing a /$filter(...) path segment?

Then the general rule is
- the path shapes/defines the input
- the query options shape/define the output

> Allow $expand and $select with modifying requests that return a collection in combination with return=representation to specify the response shape
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-1018
>                 URL: https://issues.oasis-open.org/browse/ODATA-1018
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: Protocol, URL Conventions
>    Affects Versions: V4.0_OS
>         Environment: Proposed
>            Reporter: Hubert Heijkers
>            Assignee: Michael Pizzo
>              Labels: Usability
>             Fix For: V4.01_CSD02
>
>
> This is a clone of ODATA-614 in which we allowed to use $expand and $select already for single entities.
> While discussing this in our meeting on December 1st, we concluded that there is no reason to not allow this for collections either.
> The proposed solution is pretty much just allowing what we already allowed for requests returning a single resource to collections as well. Re-reading the proposal though I wonder if it is obvious that returning 'No Content' implies it couldn't return what was requested but still executed the request. I'm not proposing to fail the request just not sure if the response is in line with what one expects/what a GET request would do if it were asked the same???



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)