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

Clarify rules around results returned from Create/Update #388

Open
ralfhandl opened this issue Mar 20, 2024 · 0 comments
Open

Clarify rules around results returned from Create/Update #388

ralfhandl opened this issue Mar 20, 2024 · 0 comments
Assignees
Labels
Protocol Protocol, URL Conventions V4.02

Comments

@ralfhandl
Copy link
Contributor

In ODATA-1609 we defined that a create or update request with query parameters would return success if the resource was created or updated, even if a response could not be generated.

Clients can specify that they desire a response through a Prefer header (return=representation).

In 4.01 we added the ability for the client to specify select and expand query options for a create/update request, and suggested that presence of the select or expand would imply the user's intent to return results. However, with OData-1609 we are left with a situation in which the select and expand is ignored and yet we return a success code, meaning that adding select and expand indicates, at most, a preference, rather than a requirement to return results.

In 4.02 we should clarify that clients should couple the addition of a $select/$expand to a create/update statement with a return=representation preference if they want a result returned. Services then return a preference-applied header specifying return=representation if a response can be returned, or return=minimal if no response is returned. Note that it is always valid for the service to return a result even if the create/update is not specified, so any services that return results without the presence of a return=representation are not out of compliance, but clients should specify the preference as well as any select or expand in order to get results.

Alternatively, we could say that the presence of a $select/$expand implicitly sets the preference for return=representation, and the service should behave as if a return=representation preference had been explicitly specified, including returning a preference-applied (unless a return preference had been explicitly specified, in which case it should take precedence – i.e., if the client specifies $select/$expand and return=minimal, then service should omit a response body).

Proposal

Clarify that clients wanting a result returned from a create or update SHOULD specify a return=representation preference and MAY additionally specify $select and/or $expand to specify how results are returned. Services SHOULD return a preference-applied header specifying return=representation if a response is returned, or return=minimal if the create/update succeeds and no response is returned, for example, because the service doesn't support returning results from create/update, the requested query options could not be honored, or due to a service issue between create/update and selecting the results.

Imported from ODATA-1616

@ralfhandl ralfhandl added Protocol Protocol, URL Conventions V4.02 labels Mar 20, 2024
@HeikoTheissen HeikoTheissen modified the milestone: 4.02 Mar 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Protocol Protocol, URL Conventions V4.02
Projects
Status: Open
Development

No branches or pull requests

3 participants