3.2.5.5 Executing a Received Update Request

The directives defined in this section apply when executing a received request of any of the Update request types that are defined in Update Request Types (section 2.2.7.3).

The server MUST validate the HTTP request URI identified as an existing EntityType, ComplexType instance, primitive property, Media Resource, or Link, as defined by the data service's data model in Abstract Data Model (section 2.2.1). If this validation fails, a 4xx error response code MUST be returned, as specified in Common Response Codes (section 3.2.8). If the validation succeeds, the server MUST update the value of the resource identified by the request URI with the values specified in the request's payload.

If the Update request used the HTTP PUT method, the request MUST be processed by first setting the resource identified in the request URI to its default value(s) and then updating the default value(s) with those provided in the request payload.

If the Update request used the HTTP PATCH or HTTP MERGE method, the request MUST be processed using a merge-based update, as specified in PATCH/MERGE (section 2.2.4.1).

The HTTP MERGE, HTTP PATCH, and HTTP PUT methods are defined by this document to have identical semantics for UpdateProperty (section 2.2.7.3.3), UpdateLink (section 2.2.7.3.6), and UpdateValue (section 2.2.7.3.5) request types. Thus, when servers execute such requests, there MUST NOT be any observable difference (from the client's perspective) between a successful response to a request made by using the HTTP MERGE method and the same request made by using the HTTP PUT method.

If an Update request is received that would set the value of a data service resource to null when the type of that resource is not nullable, as defined by the Entity Data Model associated with the data service, then the server MUST return a 4xx response code, as specified in Common Response Codes (section 3.2.8).

If an Update request is received that would set the value of a resource to empty when the type of that resource does not define an empty state, the server MUST return a 4xx response code, as specified in Common Response Codes (section 3.2.8).<73>

Any inlined content in an Update request payload SHOULD be ignored, as specified in Inline Representation (section 2.2.6.2.6.1), Deferred Content (section 2.2.6.3.9), and Inline Representation (section 2.2.6.3.9.1).

If the request URI does not match associated URIs that are anywhere in the request payload where URIs are expected, then the request URI takes precedence and the payload MAY be treated as if the URIs in it match the value of the request URI.

If the payload of an Update request contains, as part of the serialization of a resource, one or more of the key properties for the associated EntityType, those key values MUST be ignored by the server because EntityKeys are immutable.

If the request URI identifies a property P of an OpenEntityType instance and P does not represent a declared property or NavigationProperty of the entity, then P MUST be considered to represent a dynamic property, and the request represents a request to update the value of P.

In OData 1.0 and OData 2.0, if the update succeeds in full, the server MUST return a 204 (No Content) response code.

In OData 3.0, the response MAY have a 200 response code, as specified in [RFC2616], if the response body includes the updated values as they exist on the server.