[OASIS Issue Tracker] Commented: (ODATA-37) UPSERT: allow PUT and PATCH to the URL of a not yet existing entity to create this entity

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32667#action_32667 ] 

Michael Pizzo commented on ODATA-37:
------------------------------------

A couple of comments:
-for a PATCH request to succeed as an insert, it must include all non-nullable properties that don't have a default value.
-as long as there is a URL that represents a single resource, if the server generates key properties we still *could* support upsert to that URL. For example, if you have a URL that represents a singleton relationship... i.e. 

PUT ~/Orders(123)/Customer

A service that assigned key properties (i.e., CustomerID) *could* support PUT/PATCH to such a URL without the client specifying the key.

I don't know how important this scenario is, and we should probably explicitly state whether or not such a thing is supported.

> UPSERT: allow PUT and PATCH to the URL of a not yet existing entity to create this entity 
> ------------------------------------------------------------------------------------------
>
>                 Key: ODATA-37
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-37
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>            Priority: Minor
>             Fix For: V4.0_WD01
>
>
> HTTP semantics of PUT and PATCH allow inserting new entities; PUT specifies the desired after-image.
> Example: 
> PUT ~/Employees(12345)
> <full entity body>
> would update employee 12345 if it exists, and create it if it doesn't exist yet.
> Note: the PUT request targets the entity URL, not the entity set URL, so the client chooses the values of the key properties, not the server. Where this is not permissible (e.g. if the key comes from a server-managed number range), the request MUST be rejected.
> This is desirable in some cases and saves GET requests to check for existence.
> If the client only wants to update existing resources, it MAY include an If-Match header, either with a specific ETag value, or with "*".
> RFC2616, section 14.24 explicitly describes If-Match:* for "update only if existing".
> If ODATA-39 is applied as proposed, the new paragraph in section 8.2.4 must be relaxed to allow inserting new entities without specifying an If-Match request header.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira