diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html index aa370153e..8a22b2792 100644 --- a/docs/odata-protocol/odata-protocol.html +++ b/docs/odata-protocol/odata-protocol.html @@ -1759,7 +1759,7 @@
If the entity being created is not an open entity, additional property values beyond those specified in the metadata SHOULD NOT be sent in the request body. The service MUST fail if unable to persist all property values specified in the request.
Properties computed by the service (annotated with the term Core.Computed
, see OData-VocCore) and properties that are tied to properties of the principal entity by a referential constraint, can be omitted and MUST be ignored if included in the request.
Properties with a defined default value, nullable properties, and collection-valued properties omitted from the request are set to the default value, null, or an empty collection, respectively.
-Upon successful creation of the entity, the service MUST respond with either 201 Created
and a representation of the created entity, or 204 No Content
if the request included a return=minimal
preference and did not include the system query options $select
and $expand
, or if a representation of the created entity could not be constructed. In either case, the response MUST contain a Location
header that contains the edit URL or read URL of the created entity. If the service could not even construct the Location
header of the created entity, it SHOULD still respond with 204 No Content
, so the client can determine the created entity with a collection query.
Upon successful creation of the entity, the service MUST respond with either 201 Created
and a representation of the created entity, or 204 No Content
if the request included a return=minimal
preference and did not include the system query options $select
and $expand
, or if a representation of the created entity could not be constructed. In either case, if the service is able to construct the edit URL or read URL of the created entity, the response MUST contain that URL in a Location
header.
To create a new entity with links to existing entities in a single request, the client includes references to the related entities in the request body.
The representation for referencing related entities is format-specific.
@@ -1816,7 +1816,7 @@If an update specifies both a binding to a single-valued navigation property and a dependent property that is tied to a key property of the principal entity according to the same navigation property, then the dependent property is ignored, and the relationship is updated according to the value specified in the binding.
If the entity being updated is open, then additional values for properties beyond those specified in the metadata or returned in a previous request MAY be sent in the request body. The service MUST treat these as dynamic properties.
If the entity being updated is not open, then additional values for properties beyond those specified in the metadata or returned in a previous request SHOULD NOT be sent in the request body. The service MUST fail if it is unable to persist all updatable property values specified in the request.
-Upon successful completion of the update, the service responds with either 200 OK
and a representation of the updated entity, or 204 No Content
. The client may request that the response SHOULD include a body by specifying a return=representation
preference, or by specifying the system query options $select
or $expand
. If the service uses ETags for optimistic concurrency control, the entities in the response MUST include ETags. If a representation of the updated entity could not be constructed, the service can ignore this preference and respond with 204 No Content
.
Upon successful completion of the update, the service responds with either 200 OK
and a representation of the updated entity, or 204 No Content
. The client may request that the response SHOULD include a body by specifying a return=representation
preference, or by specifying the system query options $select
or $expand
. If the service uses ETags for optimistic concurrency control, the entities in the response MUST include ETags. If a representation of the updated entity could not be constructed, the service can ignore the system query options and respond with 204 No Content
.
Update requests with an OData-Version header with a value of 4.0
MUST NOT contain related entities as inline content. Such requests MAY contain binding information for navigation properties. For single-valued navigation properties this replaces the relationship. For collection-valued navigation properties this adds to the relationship.
Payloads with an OData-Version
header with a value of 4.01
or greater MAY include nested entities and entity references that specify the full set of to be related entities, or a nested delta payload representing the related entities that have been added, removed, or changed. Such a request is referred to as a “deep update”. If the nested collection is represented identical to an expanded navigation property, then the set of nested entities and entity references specified in a successful update request represents the full set of entities to be related according to that relationship and MUST NOT include added links, deleted links, or deleted entities.