OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (ODATA-37) UPSERT: allow PUT to create new entities


     [ http://tools.oasis-open.org/issues/browse/ODATA-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-37:
----------------------------

    Description: 
HTTP semantics of PUT allows inserting new entities; PUT specifies the desired after-image.

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 entitities without specifying an If-Match request header.

  was:
HTTP semantics of PUT allows inserting new entities; PUT specifies the desired after-image.

While desirable in some cases (saves GET requests to check for existence) it may be problematic if the client only wants to update if the target entity still exists, and not if it has been deleted in the mean-time. It also introduces a new error scenario for mis-spelled keys.


> UPSERT: allow PUT to create new entities 
> -----------------------------------------
>
>                 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 v1.0
>    Affects Versions: WD01
>            Reporter: Ralf Handl
>            Priority: Minor
>             Fix For: WD01
>
>
> HTTP semantics of PUT allows inserting new entities; PUT specifies the desired after-image.
> 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 entitities 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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]