Subject: Re: [core] Patch idempotent?

From: "weigengyu" <[email-masked]>
Date: Tue, 4 Aug 2015 10:51:44 +0800

Hi Robert: 

Robert Cragie wrote:
> The partial operation of PATCH also implies its operation in a sequence.
> Then the idempotency of the whole sequence needs to be considered. 

Yes, it needs considering for some applications. 
According to the reference RFC about HTTP Patch, “the client  can use a strong ETag [RFC2616] in an If-Match header on the PATCH request."
For beign defined CoAP Patch, it is possible to use the same( or similar) way for getting idmpotent. 

So, one CoAP Patch would be enough. and CoAP iPatch would not be required.

Regards,

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Robert Cragie 
Sent: Thursday, July 30, 2015 4:27 PM
To: weigengyu 
Cc: mailto:[email-masked] ; [email-masked] 
Subject: Re: [core] Patch idempotent?

I tend to agree - why does PATCH need to be idempotent? Only two of its applications (replace, delete) seem obviously idempotent. The partial operation of PATCH also implies its operation in a sequence. Then the idempotency of the whole sequence needs to be considered. 

Robert

On 29 July 2015 at 10:22, weigengyu <[email-masked]> wrote:

  HI Peter,

  It seems not to be a critical issue to be idempotent.
  Probably, conditional request can handle this issue.

  In RFC5789,
  "PATCH is neither safe nor idempotent as defined by [RFC2616], Section 9.1."
  "A PATCH request can be issued in such a way as to be idempotent,
    which also helps prevent bad outcomes from collisions between two
    PATCH requests on the same resource in a similar time frame.
  Collisions from multiple PATCH requests may be more dangerous than
  PUT collisions because some patch formats need to operate from a
  known base-point or else they will corrupt the resource.  Clients
  using this kind of patch application SHOULD use a conditional request
  such that the request will fail if the resource has been updated
  since the client last accessed the resource.  For example, the client
  can use a strong ETag [RFC2616] in an If-Match header on the PATCH request."

  In RFC 6902, it is not mention to be idempotent.
  "JavaScript Object Notation (JSON) [RFC4627] is a common format for
  the exchange and storage of structured data.  HTTP PATCH [RFC5789]
  extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a
  method to perform partial modifications to resources."
  "JSON Patch is a format (identified by the media type "application/
    json-patch+json") for expressing a sequence of operations to apply to
    a target JSON document; it is suitable for use with the HTTP PATCH method."

  Regards,

  Gengyu WEI
  Network Technology Center
  School of Computer
  Beijing University of Posts and Telecommunications
  -----原始邮件----- From: peter van der Stok
  Sent: Tuesday, July 28, 2015 5:42 PM
  To: Core
  Subject: [core] Patch idempotent? 

  Hi all,

  During the CoRE meeting on friday, the suggestion was done that an
  idem-potent patch in CoAP should be called iPatch and that Patch itself
  is not necessarily idempotent.

  I can identify 2 reasons why patch should not be idempotent:

  1) the patch adds new sections to a resource and is not idem-potent when
  for example new sections are identified by invocation date and time.
  2) the patch changes the content of the resource as function of the
  resource state e.g. incrementing its values

  Other possibilities, not identified by me, may exist.

  3) An idempotent Patch can be restricted to replacing a subset of the
  variables in the resource to the same subset with possibly different
  values.

  RF6902 restricts its operations to add, remove, move, copy, replace.
  The way the operations add, remove, replace are specified in 6902
  implies their idem-potency; copy and move are not because dependent on
  the resource state.

  RFC7396 supports only the operations add, remove and replace, and is
  consequently an idem-potent format.

  My proposal is to specify Patch for CoAP to be non-idempotent conforming
  to the http interpretation.
  This being said, we can add a new method to CoAP, called "iPatch", which
  is idem-potent and probably fulfils what most applications want Patch to
  do (RFC7396 semantics).

  The Patch command could then also include RPC semantics like toggle, or
  INC(x), or actuator settings, currently excluded by an idem-potent PUT
  in CoAP.

  Looking forward to other opinions,

  peter

  -- 
  Peter van der Stok
  vanderstok consultancy
  mailto: [email-masked]
  www: www.vanderstok.org
  tel NL: +31(0)492474673     F: +33(0)966015248

  _______________________________________________
  core mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/core

  _______________________________________________
  core mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/core

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 6 Aug 2015 14:40:27 +0000

Hi all

It might be worth check this also in the context of RD and the registration update: Originally, RD used PUT to leverage the idempotency property when adding resources/links. We now changed this to POST, since the intent is not to replace the resource state with the request body, but to modify it. This is a call for PATCH. Is it enough that in the context of Link Format, a PATCH would be idempotent because link entries must be unique and duplicate attributes make no sense?

Ciao
Matthias

---

From: peter van der Stok <[email-masked]>
Date: Fri, 07 Aug 2015 09:45:01 +0200

Hi Matthias,

It is possibly a good approach to use Patch for RD and make the patch 
invocation idem-potent.
However, this is different from demanding that Patch is idem-potent on 
all servers.
Is the provision of iPatch an asset for servers which, in the absence of 
iPatch, assure that Patch is idem-potent?

Peter

Kovatsch  Matthias schreef op 2015-08-06 16:40:
> Hi all
> 
> It might be worth check this also in the context of RD and the
> registration update: Originally, RD used PUT to leverage the
> idempotency property when adding resources/links. We now changed this
> to POST, since the intent is not to replace the resource state with
> the request body, but to modify it. This is a call for PATCH. Is it
> enough that in the context of Link Format, a PATCH would be idempotent
> because link entries must be unique and duplicate attributes make no
> sense?
> 
> Ciao
> 
> Matthias
> 
>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 7 Aug 2015 13:32:45 +0000

Hi Peter

> However, this is different from demanding that Patch is idem-potent on all
> servers.

Clients usually do not know the server implementation. They have to rely on the properties given through the methods. For instance, a client can always be sure that a GET has no side-effects on the server (unless the server has an erroneous implementation...). For RD, we would have out-of-band information, but this is exactly the kind of coupling REST tries to avoid.

> Is the provision of iPatch an asset for servers which, in the absence of iPatch,
> assure that Patch is idem-potent?

Not for servers, but for clients. Recovery in case of no response becomes much easier, for instance.
However, I am not in favor of having two different PATCH methods... let's keep it simple! :)

Ciao
Matthias

---

From: peter van der Stok <[email-masked]>
Date: Mon, 10 Aug 2015 08:25:08 +0200

Hi Matthias,

Not sure what your recommendations is:
- No iPatch and Patch must be idempotent
- No iPatch and Patch is preferred to be idempotent.

Peter

Kovatsch  Matthias schreef op 2015-08-07 15:32:
>> all
> Clients usually do not know the server implementation. They have to
> rely on the properties given through the methods. For instance, a
> client can always be sure that a GET has no side-effects on the server
> (unless the server has an erroneous implementation...). For RD, we
> would have out-of-band information, but this is exactly the kind of
> coupling REST tries to avoid.
>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 11 Aug 2015 12:00:14 +0000

Hi Peter

> Not sure what your recommendations is

In my opinion, we should:

- Keep things simple
- Only have one PATCH method in CoAP
- Design PATCH in such a way that it actually has a benefit over POST, that is, clear semantics and/or better properties (e.g., idempotency)

However, I am sure people thought a lot about HTTP PATCH and idempotency is hard to achieve. Some random thoughts (sorry, I currently cannot work on this properly...):

Do we always require "patch documents" (i.e., special media types)? We could make PATCH with a "normal media type" behave like what was intended with PUT in RD, that is, adding the entries of the request body to the resource without replacing the entire resource (which is expected from PUT).

I am not sure if a MUST for ETags would be a valid approach: servers/resources supporting PATCH must provide ETags and clients must include the If-Match option in PATCH requests with. Maybe the latter can be limited to patch document types, which are hard to make idempotent.

Regards
Matthias

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Aug 2015 10:41:12 -0700

On Tue, Aug 11, 2015 at 5:00 AM, Kovatsch Matthias <[email-masked]>
wrote:

> - Design PATCH in such a way that it actually has a benefit over POST,
> that is, clear semantics and/or better properties (e.g., idempotency)
>
> However, I am sure people thought a lot about HTTP PATCH and idempotency
> is hard to achieve. Some random thoughts (sorry, I currently cannot work on
> this properly...):
>
> Do we always require "patch documents" (i.e., special media types)? We
> could make PATCH with a "normal media type" behave like what was intended
> with PUT in RD, that is, adding the entries of the request body to the
> resource without replacing the entire resource (which is expected from PUT).
>
> I am not sure if a MUST for ETags would be a valid approach:
> servers/resources supporting PATCH must provide ETags and clients must
> include the If-Match option in PATCH requests with. Maybe the latter can be
> limited to patch document types, which are hard to make idempotent.
>
>

What is wrong with using ETags and If-Match if the server wants to support
this feature?
PATCH is very important to CoMI because it maps to a "merge" in YANG.
This allows the client to send only the parts of the resource that are
changing,
instead of the whole thing.  This will likely be 20:1 or 100:1 savings
every time
PATCH is used instead of PUT in CoMI.

Regards
> Matthias
Andy

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 11 Aug 2015 17:55:27 +0000

From: Andy Bierman [mailto:[email-masked]]
What is wrong with using ETags and If-Match if the server wants to support this feature?

Nothing is wrong with that. It would just be simpler and more elegant if we could find a way to be idempotent without ETag checks. My other thought was more on enforcing these checks if we cannot come up with the “elegant way.” This way, there would be a lower probability that clients corrupt the resource state.

This allows the client to send only the parts of the resource that are changing,
instead of the whole thing.  This will likely be 20:1 or 100:1 savings every time
PATCH is used instead of PUT in CoMI.

Yes, the requirement of sending only deltas is clear to me. I am just saying that it can also be implemented with POST if the PATCH method itself does not provide defined properties to the client. In both cases, the client only can hope that the server will do the right thing.

Regards
Matthias

---

From: peter van der Stok <[email-masked]>
Date: Thu, 20 Aug 2015 15:19:58 +0200

Hi all,

It seems that people want one coap Patch command, which is preferably 
idem potent to facilitate application development.
On the other hand some people express the wish to have the opportunity 
to write non idem potent patch services.

I propose to change the text in the Coap patch draft to:

The Patch method is RECOMMENDED to be idem-potent such that replace, 
add, and delete operations, as specified in RFC7396, can be executed in 
an idem-potent fashion
with the caveats with respect to add and delete operations as mentioned 
in RFC 6902 appendices.

Any dissatisfaction with this text?

Peter

---

From: Paul Duffy <[email-masked]>
Date: Tue, 25 Aug 2015 11:21:29 -0400

Please try to maintain consistency with 5789 PATCH.  This to ease 
translation between HTTP and CoAP.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Aug 2015 18:06:37 +0200

As Paul said, we need to position ourselves with respect to HTTP's
PATCH.  Whatever we call PATCH will have to work like HTTP's PATCH.

Saying that PATCH is "recommended" to be idempotent is essentially
identical to saying it's not -- an implementation will not be able to
rely on this behavior if it is just recommended.  We might as well
mirror HTTP and completely forget about this idempotency simplification.
 Origin server implementers may still be able to derive idempotency from
the properties of the patch media type.

However, I don't buy the argument that adding two methods makes things
more complex -- nothing is more complex than having to guess what was
meant.  Saying it in plain language (e.g., spelling out either a PATCH
method with no idempotency guarantees or an IPATCH method that does
guarantee idempotency) makes the life of the implementer much simpler.

(On simple servers, I would actually only implement IPATCH.)

Grüße, Carsten