The apply expression enables a value to be obtained by applying a client-side function. The apply expression MAY have operand expressions. The operand expressions are used as parameters to the client-side function.
-$Apply$Apply and $FunctionApply expressions are represented as an object with a member $Apply whose value is an array of annotation expressions, and a member $Function whose value is a string containing the qualified name of the client-side function to be applied.
It MAY contain annotations.
The cast expression casts the value obtained from its single child expression to the specified type. The cast expression follows the same rules as the cast canonical function defined in OData-URL.
$Cast$CastCast expressions are represented as an object with a member $Cast whose value is an annotation expression, a member $Type whose value is a string containing the qualified type name, and optionally a member $Collection with a value of true.
It MAY contain annotations.
If the specified type is a primitive type or a collection of primitive types, the facet members $MaxLength, $Unicode, $Precision, $Scale, and $SRID MAY be specified if applicable to the specified primitive type. If the facet members are not specified, their values are considered unspecified.
The second and third child expressions are evaluated conditionally. The result MUST be type compatible with the type expected by the surrounding expression.
If the first expression evaluates to true, the second expression MUST be evaluated and its value MUST be returned as the result of the if-then-else expression. If the first expression evaluates to false and a third child element is present, it MUST be evaluated and its value MUST be returned as the result of the if-then-else expression. If no third expression is present, nothing is added to the surrounding collection.
$If$IfConditional expressions are represented as an object with a member $If whose value is an array of two or three annotation expressions.
It MAY contain annotations.
$IfThe is-of expression checks whether the value obtained from its single child expression is compatible with the specified type. It returns true if the child expression returns a type that is compatible with the specified type, and false otherwise.
$IsOf$IsOfIs-of expressions are represented as an object with a member $IsOf whose value is an annotation expression, a member $Type whose value is a string containing an qualified type name, and optionally a member $Collection with a value of true.
It MAY contain annotations.
If the specified type is a primitive type or a collection of primitive types, the facet members $MaxLength, $Unicode, $Precision, $Scale, and $SRID MAY be specified if applicable to the specified primitive type. If the facet members are not specified, their values are considered unspecified.
A labeled element expression MUST contain exactly one child expression. The value of the child expression is also the value of the labeled element expression.
A labeled element expression MUST provide a simple identifier value as its name that MUST be unique within the schema containing the expression.
$LabeledElement$LabeledElementLabeled element expressions are represented as an object with a member $LabeledElement whose value is an annotation expression, and a member $Name whose value is a string containing the labeled element’s name.
It MAY contain annotations.
$LabeledEle
14.4.10 Labeled Element Reference
The labeled element reference expression MUST specify the qualified name of a labeled element expression in scope and returns the value of the identified labeled element expression as its value.
- $LabeledElementReference
+ $LabeledElementReference
Labeled element reference expressions are represented as an object with a member $LabeledElementReference whose value is a string containing an qualified name.
@@ -3179,7 +3179,7 @@ 14.4.11 Null
"@UI.DisplayName": null,
- $Null
+ $Null
Null expression containing annotations are represented as an object with a member $Null whose value is the literal null.
@@ -3235,7 +3235,7 @@ 14.4.13
The URL reference expression MUST contain exactly one expression of type Edm.String. Its value is treated as a URL that MAY be relative or absolute; relative URLs are relative to the URL of the document containing the URL reference expression, or relative to a base URL specified in a format-specific way.
The response body of the GET request MUST be returned as the result of the URL reference expression. The result of the URL reference expression MUST be type compatible with the type expected by the surrounding expression.
- $UrlRef
+ $UrlRef
URL reference expressions are represented as an object with a single member $UrlRef whose value is an annotation expression.
It MAY contain annotations.
@@ -3799,13 +3799,14 @@ $DivBy
$Mod$Apply$Cast$If$IsOf$LabeledElement$LabeledElementReference$Null$UrlRef$Function$Cast$If$IsOf$LabeledElement$LabeledElementReference$Null$UrlRef
diff --git a/docs/odata-csdl-json/odata-csdl-json.md b/docs/odata-csdl-json/odata-csdl-json.md
index 4ff23c496..71e397f61 100644
--- a/docs/odata-csdl-json/odata-csdl-json.md
+++ b/docs/odata-csdl-json/odata-csdl-json.md
@@ -4909,7 +4909,7 @@ The operand expressions are used as parameters to the client-side
function.
::: {.varjson .rep}
-### `$Apply`
+### `$Apply` and `$Function`
Apply expressions are represented as an object with a member `$Apply`
whose value is an array of annotation expressions, and a member
@@ -5090,7 +5090,7 @@ rules as the `cast` canonical function defined in
[OData-URL](#ODataURL).
::: {.varjson .rep}
-### `$Cast`
+### `$Cast`
Cast expressions are represented as an object with a member `$Cast`
whose value is an annotation expression, a member `$Type` whose value is
@@ -5173,7 +5173,7 @@ third expression is present, nothing is added to the surrounding
collection.
::: {.varjson .rep}
-### `$If`
+### `$If`
Conditional expressions are represented as an object with a member `$If`
whose value is an array of two or three annotation expressions.
@@ -5208,7 +5208,7 @@ child expression is compatible with the specified type. It returns
the specified type, and `false` otherwise.
::: {.varjson .rep}
-### `$IsOf`
+### `$IsOf`
Is-of expressions are represented as an object with a member `$IsOf`
whose value is an annotation expression, a member `$Type` whose value is
@@ -5255,7 +5255,7 @@ identifier](#SimpleIdentifier) value as its name that MUST be unique
within the schema containing the expression.
::: {.varjson .rep}
-### `$LabeledElement`
+### `$LabeledElement`
Labeled element expressions are represented as an object with a member
`$LabeledElement` whose value is an annotation expression, and a member
@@ -5286,7 +5286,7 @@ in scope and returns the value of the identified labeled element
expression as its value.
::: {.varjson .rep}
-### `$LabeledElementReference`
+### `$LabeledElementReference`
Labeled element reference expressions are represented as an object with
a member `$LabeledElementReference` whose value is a string containing
@@ -5322,7 +5322,7 @@ Example 85:
:::
::: {.varjson .rep}
-### `$Null`
+### `$Null`
Null expression containing [annotations](#Annotations) are represented
as an object with a member `$Null` whose value is the literal `null`.
@@ -5433,7 +5433,7 @@ expression MUST be type compatible with the type expected by the
surrounding expression.
::: {.varjson .rep}
-### `$UrlRef`
+### `$UrlRef`
URL reference expressions are represented as an object with a single
member `$UrlRef` whose value is an annotation expression.
@@ -6072,13 +6072,14 @@ https://openui5.hana.ondemand.com/1.40.10/#docs/guide/87aac894a40640f89920d7b2a4
- [`$DivBy`](#DivBy21.18)
- [`$Mod`](#Mod21.19)
- [`$Apply`](#Apply21.20)
- - [`$Cast`](#Cast21.21)
- - [`$If`](#If21.22)
- - [`$IsOf`](#IsOf21.23)
- - [`$LabeledElement`](#LabeledElement21.24)
- - [`$LabeledElementReference`](#LabeledElementReference21.25)
- - [`$Null`](#Null21.26)
- - [`$UrlRef`](#UrlRef21.27)
+ - [`$Function`](#Function21.21)
+ - [`$Cast`](#Cast21.22)
+ - [`$If`](#If21.23)
+ - [`$IsOf`](#IsOf21.24)
+ - [`$LabeledElement`](#LabeledElement21.25)
+ - [`$LabeledElementReference`](#LabeledElementReference21.26)
+ - [`$Null`](#Null21.27)
+ - [`$UrlRef`](#UrlRef21.28)
:::
-------
diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html
index 4c5a3eff6..d33b84570 100644
--- a/docs/odata-protocol/odata-protocol.html
+++ b/docs/odata-protocol/odata-protocol.html
@@ -483,10 +483,22 @@ 1 Introducti
The OData-CSDLXML specification defines an XML representation of the entity data model exposed by an OData service.
The OData-JSON document specifies the JSON format of the resource representations that are exchanged using OData.
1.1 Changes from Earlier Versions
-
-
-
-
+
+
+
+Section
+Feature / Change
+Issue
+
+
+
+
+Section 11.4
+Response code 204 No Content after successful data modification if requested response could not be constructed
+ODATA-1609
+
+
+
1.2 Glossary
1.2.1 Definitions of Terms
1.2.2 Acronyms and Abbreviations
@@ -886,7 +898,7 @@ Data Service Request has been accepted and has not yet completed executing asynchronously. The asynchronous handling of requests is defined in the sections on Asynchronous Requests and Asynchronous Batch Requests.
9.1.4 Response Code 204 No Content
A request returns 204 No Content if the requested resource has the null value, or if the service applies a return=minimal preference. In this case, the response body MUST be empty.
-As defined in RFC7231, a Data Modification Request that responds with 204 No Content MAY include an ETag header with a value reflecting the result of the data modification if and only if the client can reasonably “know” the new representation of the resource without actually receiving it. For a PUT request this means that the response body of a corresponding 200 OK or 201 Created response would have been identical to the request body, i.e. no server-side modification of values sent in the request body, no server-calculated values etc. For a PATCH request this means that the response body of a corresponding 200 OK or 201 Created response would have consisted of all values sent in the request body, plus (for values not sent in the request body) server-side values corresponding to the ETag value sent in the If-Match header of the PATCH request, i.e. the previous values “known” to the client.
+As defined in RFC7231, a Data Modification Request that responds with 204 No Content MAY include an ETag header with a value reflecting the result of the data modification if and only if the client can reasonably “know” the new representation of the resource without actually receiving it. For a PUT request this means that the response body of a corresponding 200 OK or 201 Created response would have been identical to the request body, i.e. no server-side modification of values sent in the request body, no server-calculated values etc. For a PATCH request this means that the response body of a corresponding 200 OK or 201 Created response would have consisted of all values sent in the request body, plus (for values not sent in the request body) server-side values corresponding to the ETag value sent in the If-Match header of the PATCH request, i.e. the previous values “known” to the client.
9.1.5 Response Code 3xx Redirection
As per RFC7231, a 3xx Redirection indicates that further action needs to be taken by the client in order to fulfill the request. In this case, the response SHOULD include a Location header, as appropriate, with the URL from which the result can be obtained; it MAY include a Retry-After header.
9.1.6 Response Code 304 Not Modified
@@ -1712,7 +1724,7 @@ 11.3.
11.4 Data Modification
Updatable OData services support Create, Update, and Delete operations for some or all exposed entities. Additionally, Actions supported by a service can affect the state of the system.
A successfully completed Data Modification Request must not violate the integrity of the data.
-The client may request whether content be returned from a Create, Update, or Delete request, or the invocation of an Action, by specifying the return preference.
+The client may request whether content be returned from a Create, Update, or Delete request, or the invocation of an Action, by specifying the return preference. A success response indicates that data have been modified, regardless of whether the requested content could be returned.
11.4.1 Common Data Modification Semantics
Data Modification Requests share the following semantics.
11.4.1.1 Use of ETags for Avoiding Update Conflicts
@@ -1748,8 +1760,7 @@ 1
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 completion, the response MUST contain a Location header that contains the edit URL or read URL of the created entity.
-Upon successful completion 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.
+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.
11.4.2.1 Link to Related Entities When Creating an Entity
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.
@@ -1806,7 +1817,7 @@ 1
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 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.
+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 MAY ignore the system query options and respond with 204 No Content.
11.4.3.1 Update Related Entities When Updating an Entity
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.
@@ -2283,15 +2294,18 @@
Example 102:
-GET /path/service/People(1) HTTP/1.1
-Host: myserver.mydomain.org:1234
+PATCH /path/service/People(1) HTTP/1.1
+Host: myserver.mydomain.org:1234
+Content-Type: application/json
+
+{"Name": "Peter"}
- Resource path relative to the batch request URI.
Example 103:
-GET People(1) HTTP/1.1
+DELETE People(1) HTTP/1.1
Services MUST support all three formats for URLs of individual requests.
URLs must be correctly percent-encoded. For relative URLs this means that colons in the path part, especially within key values, MUST be percent-encoded to avoid confusion with the scheme separator. Colons within the query part, i.e. after the question mark character (?), need not be percent-encoded.
diff --git a/docs/odata-protocol/odata-protocol.md b/docs/odata-protocol/odata-protocol.md
index 7d39f37c9..b08e927dd 100644
--- a/docs/odata-protocol/odata-protocol.md
+++ b/docs/odata-protocol/odata-protocol.md
@@ -344,8 +344,9 @@ resource representations that are exchanged using OData.
## 1.1 Changes from Earlier Versions
-
-
+Section | Feature / Change | Issue
+--------|------------------|------
+[Section 11.4](#DataModification)| Response code `204 No Content` after successful data modification if requested response could not be constructed| [ODATA-1609](https://issues.oasis-open.org/browse/ODATA-1609)
## 1.2 Glossary
@@ -1807,7 +1808,7 @@ In this case, the response body MUST be empty.
As defined in [RFC7231](#rfc7231), a [Data Modification
Request](#DataModification) that responds with
-`204 No Content` MAY include an `ETag` header with a value reflecting
+`204 No Content` MAY include an [`ETag`](#HeaderETag) header with a value reflecting
the result of the data modification if and only if the client can
reasonably "know" the new representation of the resource without
actually receiving it. For a `PUT` request this means that the response
@@ -3963,6 +3964,8 @@ must not violate the integrity of the data.
The client may request whether content be returned from a Create,
Update, or Delete request, or the invocation of an Action, by specifying
the [`return`](#Preferencereturnrepresentationandreturnminimal) preference.
+A [success response](#SuccessResponses) indicates that data have been modified,
+regardless of whether the requested content could be returned.
### 11.4.1 Common Data Modification Semantics
@@ -4138,17 +4141,16 @@ 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 completion, the response MUST contain a
-[`Location`](#HeaderLocation) header that contains the edit URL or read URL of the
-created entity.
-
-Upon successful completion the service MUST respond with either
+Upon successful creation of the entity, the service MUST respond with either
[`201 Created`](#ResponseCode201Created) and a representation of the
created entity, or [`204 No Content`](#ResponseCode204NoContent) if the
request included a
[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference and did not
include the system query options [`$select`](#SystemQueryOptionselect)
-and [`$expand`](#SystemQueryOptionexpand).
+and [`$expand`](#SystemQueryOptionexpand), 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`](#HeaderLocation) header.
#### 11.4.2.1 Link to Related Entities When Creating an Entity
@@ -4342,16 +4344,18 @@ 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 the service responds with either
+Upon successful completion of the update, the service responds with either
[`200 OK`](#ResponseCode200OK) and a representation of the updated
-entity, or [`204 No Content`](#ResponseCode204NoContent). The client may
+entity, or [`204 No Content`](#ResponseCode204NoContent).
+The client may
request that the response SHOULD include a body by specifying a
[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference, or by
specifying the system query options
[`$select`](#SystemQueryOptionselect) or
[`$expand`](#SystemQueryOptionexpand). If the service uses ETags for
optimistic concurrency control, the entities in the response MUST
-include ETags.
+include ETags. If a representation of the updated entity could not be constructed,
+the service MAY ignore the system query options and respond with `204 No Content`.
#### 11.4.3.1 Update Related Entities When Updating an Entity
@@ -5852,8 +5856,11 @@ GET https://host:1234/path/service/People(1) HTTP/1.1
::: example
Example 102:
```
-GET /path/service/People(1) HTTP/1.1
+PATCH /path/service/People(1) HTTP/1.1
Host: myserver.mydomain.org:1234
+Content-Type: application/json
+
+{"Name": "Peter"}
```
:::
@@ -5862,7 +5869,7 @@ Host: myserver.mydomain.org:1234
::: example
Example 103:
```
-GET People(1) HTTP/1.1
+DELETE People(1) HTTP/1.1
```
:::
diff --git a/odata-csdl/14 Vocabulary and Annotation.md b/odata-csdl/14 Vocabulary and Annotation.md
index eac9586f6..c90f0429a 100644
--- a/odata-csdl/14 Vocabulary and Annotation.md
+++ b/odata-csdl/14 Vocabulary and Annotation.md
@@ -2278,7 +2278,8 @@ The operand expressions are used as parameters to the client-side
function.
::: {.varjson .rep}
-### ##subisec `$Apply`
+### ##subisec `$Apply`
+and ##subisec `$Function`
Apply expressions are represented as an object with a member `$Apply`
whose value is an array of annotation expressions, and a member
diff --git a/odata-protocol/1 Introduction.md b/odata-protocol/1 Introduction.md
index 8ec33d691..68257c862 100644
--- a/odata-protocol/1 Introduction.md
+++ b/odata-protocol/1 Introduction.md
@@ -24,8 +24,11 @@ resource representations that are exchanged using OData.
## ##subsec Changes from Earlier Versions
-
-
+Section | Feature / Change | Issue
+--------|------------------|------
+[Section ##DataModification]|
+Response code `204 No Content` after successful data modification if requested response could not be constructed|
+[ODATA-1609](https://issues.oasis-open.org/browse/ODATA-1609)
## ##subsec Glossary
diff --git a/odata-protocol/11.4 Data Modification.md b/odata-protocol/11.4 Data Modification.md
index 01c27d5a9..bf5f0a861 100644
--- a/odata-protocol/11.4 Data Modification.md
+++ b/odata-protocol/11.4 Data Modification.md
@@ -10,6 +10,8 @@ must not violate the integrity of the data.
The client may request whether content be returned from a Create,
Update, or Delete request, or the invocation of an Action, by specifying
the [`return`](#Preferencereturnrepresentationandreturnminimal) preference.
+A [success response](#SuccessResponses) indicates that data have been modified,
+regardless of whether the requested content could be returned.
### ##subsubsec Common Data Modification Semantics
@@ -185,17 +187,16 @@ 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 completion, the response MUST contain a
-[`Location`](#HeaderLocation) header that contains the edit URL or read URL of the
-created entity.
-
-Upon successful completion the service MUST respond with either
+Upon successful creation of the entity, the service MUST respond with either
[`201 Created`](#ResponseCode201Created) and a representation of the
created entity, or [`204 No Content`](#ResponseCode204NoContent) if the
request included a
[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference and did not
include the system query options [`$select`](#SystemQueryOptionselect)
-and [`$expand`](#SystemQueryOptionexpand).
+and [`$expand`](#SystemQueryOptionexpand), 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`](#HeaderLocation) header.
#### ##subsubsubsec Link to Related Entities When Creating an Entity
@@ -389,16 +390,18 @@ 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 the service responds with either
+Upon successful completion of the update, the service responds with either
[`200 OK`](#ResponseCode200OK) and a representation of the updated
-entity, or [`204 No Content`](#ResponseCode204NoContent). The client may
+entity, or [`204 No Content`](#ResponseCode204NoContent).
+The client may
request that the response SHOULD include a body by specifying a
[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference, or by
specifying the system query options
[`$select`](#SystemQueryOptionselect) or
[`$expand`](#SystemQueryOptionexpand). If the service uses ETags for
optimistic concurrency control, the entities in the response MUST
-include ETags.
+include ETags. If a representation of the updated entity could not be constructed,
+the service MAY ignore the system query options and respond with `204 No Content`.
#### ##subsubsubsec Update Related Entities When Updating an Entity
diff --git a/odata-protocol/11.7 Batch Requests.md b/odata-protocol/11.7 Batch Requests.md
index 44e0d670b..cd923e317 100644
--- a/odata-protocol/11.7 Batch Requests.md
+++ b/odata-protocol/11.7 Batch Requests.md
@@ -206,8 +206,11 @@ GET https://host:1234/path/service/People(1) HTTP/1.1
::: example
Example ##ex:
```
-GET /path/service/People(1) HTTP/1.1
+PATCH /path/service/People(1) HTTP/1.1
Host: myserver.mydomain.org:1234
+Content-Type: application/json
+
+{"Name": "Peter"}
```
:::
@@ -216,7 +219,7 @@ Host: myserver.mydomain.org:1234
::: example
Example ##ex:
```
-GET People(1) HTTP/1.1
+DELETE People(1) HTTP/1.1
```
:::
diff --git a/odata-protocol/8 Header Fields.md b/odata-protocol/8 Header Fields.md
index 1d3c7243d..12f946af8 100644
--- a/odata-protocol/8 Header Fields.md
+++ b/odata-protocol/8 Header Fields.md
@@ -932,7 +932,7 @@ In this case, the response body MUST be empty.
As defined in [RFC7231](#rfc7231), a [Data Modification
Request](#DataModification) that responds with
-`204 No Content` MAY include an `ETag` header with a value reflecting
+`204 No Content` MAY include an [`ETag`](#HeaderETag) header with a value reflecting
the result of the data modification if and only if the client can
reasonably "know" the new representation of the resource without
actually receiving it. For a `PUT` request this means that the response