Minor 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).