Subject: [apps-discuss] A couple more PATCH issues

From: Mark Nottingham <[email-masked]>
Date: Sat, 8 Sep 2012 13:42:58 +1000

I posted a blog entry explaining why I'm keen on JSON Patch here:
  http://www.mnot.net/blog/2012/09/05/patch

In the comments, a few issues came up:

1) Thomas Koch asked how a resource know which representation the patch is intended for, against, if there are multiple representations of a resource? His example was a case where there's a portable contacts JSON format as well as a future vcard+json format available at the same URI. 

I can see a few different approaches to this; e..g,

a) letting the resource figure it out
b) using If-Match to convey the ETag of the appropriate representation
c) adding a field in the format identifying the media type of the representation that the patch is intended for

I'm sure there are more. Thoughts?

2) Markus Lanthaler asked why we don't use a +json media type. Way back when, I advised Paul to use json-patch, because +json wasn't formalised yet, and I had some philosophical issues with it (still do, but whatever).

What's the state of that now? Can we start minting +json formats? What's the process for establishing one of these? Is anyone working on a +json template in a draft (as per <http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#section-6>)?

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Fri, 7 Sep 2012 22:19:41 -0700

Sending to the list this time...
---------- Forwarded message ----------
From: "James M Snell" <[email-masked]>
Date: Sep 7, 2012 9:35 PM
Subject: Re: [apps-discuss] A couple more PATCH issues
To: "Mark Nottingham" <[email-masked]>

On Sep 7, 2012 8:43 PM, "Mark Nottingham" <[email-masked]> wrote:
> 1) Thomas Koch asked how a resource know which representation the patch
is intended for, against, if there are multiple representations of a
resource? His example was a case where there's a portable contacts JSON
format as well as a future vcard+json format available at the same URI.
> c) adding a field in the format identifying the media type of the
representation that the patch is intended for

Well, this question came up a few times when we were working through http
patch and it came down to two approaches: either leave it entirely up to
the server to figure out (e.g. who says json patch can't be applied to the
logical model that is the basis for each of the available representations)
or leave it up to the patch document format to identify the target. In
other words options (a) and (c). I don't think option (b) is that terribly
interesting or viable in the long run.

- James

> 2) Markus Lanthaler asked why we don't use a +json media type. Way back
when, I advised Paul to use json-patch, because +json wasn't formalised
yet, and I had some philosophical issues with it (still do, but whatever).
>
> What's the state of that now? Can we start minting +json formats? What's
the process for establishing one of these? Is anyone working on a +json
template in a draft (as per <
http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#section-6
>)?
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Julian Reschke <[email-masked]>
Date: Sat, 08 Sep 2012 12:03:31 +0200

> I'm sure there are more. Thoughts?

It's the same problem as with any write operation (such as PUT) to a 
content-negotiated resource. I believe the best answer is to avoid 
updates to content-negotiated resources (by using a more specific URI 
exposed by the Location header field).

Or alternatively, leave it to the server, which may have no trouble at 
all for simple conneg cases such as XML/JSON/HTML.

> ...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Sep 2012 17:53:27 +1000

On 08/09/2012, at 8:03 PM, Julian Reschke <[email-masked]> wrote:
> It's the same problem as with any write operation (such as PUT) to a content-negotiated resource. I believe the best answer is to avoid updates to content-negotiated resources (by using a more specific URI exposed by the Location header field).
> 
> Or alternatively, leave it to the server, which may have no trouble at all for simple conneg cases such as XML/JSON/HTML.

Yes; I can see documenting those possibilities.

However, I also wonder whether adding something to accommodate (c) would be helpful too; while it won't be necessary in every case, it may be for some.

Cheers,

---

From: "Paul C. Bryan" <[email-masked]>
Date: Sun, 09 Sep 2012 10:36:00 -0700

On Sat, 2012-09-08 at 13:42 +1000, Mark Nottingham wrote:

> 1) Thomas Koch asked how a resource know which representation the
> patch is intended for, against, if there are multiple representations
> of a resource? His example was a case where there's a portable
> contacts JSON format as well as a future vcard+json format available
> at the same URI.

IMO, this is a problem that HTTP PATCH has in general, and whatever
solution should address that specification.

> a) letting the resource figure it out

Seems valid. If the server can unambiguously determine which
representation to modify (e.g. because there is only one) then there is
no issue. 

> b) using If-Match to convey the ETag of the appropriate representation

Also seems valid. Presumably if there are multiple representations of
the resource, the server has to compare the ETag to all of them to
determine whether one matches. If it does this, it's certainly
unambiguous which representation to modify.

> representation that the patch is intended for

If you mean a header field, then this also seems valid. I'd suggest
though that such a solution should be addressing HTTP PATCH.

> 2) Markus Lanthaler asked why we don't use a +json media type. Way
> back when, I advised Paul to use json-patch, because +json wasn't
> formalised yet, and I had some philosophical issues with it (still do,
> but whatever).
> 
> What's the state of that now? Can we start minting +json formats?
> What's the process for establishing one of these? Is anyone working on
> a +json template in a draft (as per
> <http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#section-6>)?

+json makes sense to me when there are multiple representations of
something. Since this is very much focused on JSON document structures,
I believe it would be better to keep it as json-patch.

Paul

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Sep 2012 14:05:11 +1000

OK. 

It seems to me that we don't need any changes to the document for these, then.

Cheers,

On 10/09/2012, at 3:36 AM, Paul C. Bryan <[email-masked]> wrote:

> IMO, this is a problem that HTTP PATCH has in general, and whatever solution should address that specification.
> 
> Seems valid. If the server can unambiguously determine which representation to modify (e.g. because there is only one) then there is no issue. 
> 
> Also seems valid. Presumably if there are multiple representations of the resource, the server has to compare the ETag to all of them to determine whether one matches. If it does this, it's certainly unambiguous which representation to modify.
> 
> If you mean a header field, then this also seems valid. I'd suggest though that such a solution should be addressing HTTP PATCH.
> 
> +json makes sense to me when there are multiple representations of something. Since this is very much focused on JSON document structures, I believe it would be better to keep it as json-patch.
> 
> Paul