PATCH with contentType application/json instead of application/json-patch+json

Question

i have a question about PATCH content type. my app is spring boot application which running on public cloud. my concerns is if Patch verb could has the contentType to be application/json instead of application/json-patch+json?

any drawbacks if using plain-old json?

Answer 1

any drawbacks if using plain-old json?

Yes

Patch verb could has the contentType to be application/json instead of application/json-patch+json?

• It can
• That's not particularly useful
• You might not care that it's not particularly useful

HTTP Patch says that we should be including in the request a patch document containing

a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.

PATCH /foo HTTP/1.1
Content-Type: text/plain

Replace "ghoti" with "fish"

That's a perfectly well formed patch request, proposing an edit to the /foo resource

BUT: notice that there's some ambiguity in this example -- does this patch say to replace one instance of ghoti? or every instance of ghoti? If we want to ensure that the client and the server understand this message the same way, then they need some sort of agreement on that point.

Part of the point of REST is that these agreements should have readily standardizable forms .

Agreements about patch documents that are supported by a server are themselves described by the Accept-Patch header (defined in the HTTP Patch specification); the header values are media types; I can then find the definition of that media type to figure out how to describe my changes.

Furthermore, if the advertised media type is one I already know about, I can re-use my previous solution. Part of the point of having an application/json-patch+json standard, or an application/merge-patch+json standard, is that we all understand those documents the same way. So we get interop - any application/json-patch+json capable client can successfully communicate with any application/json-patch+json capable server.

application/json doesn't work this way, because there's nothing in the JSON specification that creates a common understanding of how to interpret a JSON document in a PATCH context. Instead, you need some other "out of band" information to do the right thing.

If interop isn't important in your context -- for instance, if you control both the server and the client implementation -- then aligning on some common standard isn't all that important either. Your web page hosts your java script that communicates with your back end, and so long as it is easy to coordinate changes here, it's not particularly important that the message schema use here match what is used elsewhere.

But if you instead are striving for "web scale" adoption, then you need to be to consider in your designs how to take advantage of general purpose work that has already been published.