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 the URL of a not yet existing entity to create this entity


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

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

        Summary: UPSERT: allow PUT to the URL of a not yet existing entity to create this entity   (was: UPSERT: allow PUT to create new entities )
       Proposal: 
Allow PUT to a URL that identifies a single, not yet existing entity to insert this entizy.

Adapt the last paragraph of section 8.2.4:

If specified, the request MUST only be invoked if the specified value matches the current ETag value of the entity. If the value does not match the current ETag value of the entity for a Data Modification Request or Action Request, the service MUST respond with 412 Precondition Failed and MUST ensure that no data is modified as a result of the request. *NEW: If the addressed entity does not exist, the provided ETag value is considered not to match.*

Adapt first paragraph of section 10.3.2:

To create an entity in a collection, send a POST request to that collection's URL. or a PUT request to the entity's URL (collection's URL followed by entity key specification for the single entity). The request body MUST contain a single valid entity representation. 


  was:
Allow PUT to insert new entities.

Adapt the last paragraph of section 8.2.4:

If specified, the request MUST only be invoked if the specified value matches the current ETag value of the entity. If the value does not match the current ETag value of the entity for a Data Modification Request or Action Request, the service MUST respond with 412 Precondition Failed and MUST ensure that no data is modified as a result of the request. *NEW: If the addressed entity does not exist, the provided ETag value is considered not to match.*

Adapt first paragraph of section 10.3.2:

To create an entity in a collection, send a POST pr PUT request to that collection's URL. The request body MUST contain a single valid entity representation. 

    Description: 
HTTP semantics of PUT allows 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

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.

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


> UPSERT: allow PUT 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 v1.0
>    Affects Versions: WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>            Priority: Minor
>             Fix For: WD01
>
>
> HTTP semantics of PUT allows 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
> 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

        


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