Is json-patch already a widespread standard?

[Szymon Bochniak]

Hello, 

I am designing a public API, and found PATCH method with json-patch+json (RFC 6902) suiting my needs very well. 

I have not found many (or even any) publicly visible APIs supporting json-patch media type. I know that RFC has been finalized in April 2013, so it's relatively fresh. The question is, whether json-patch is already an adopted standard, or it's just a standardized proposition which did not really catch up (yet)? I want to design an API which has well defined semantics, but don't want to stick to a 'niche standard' just because I found it useful (lack of client libraries etc). 

What do you, dear API crafters, think about PATCH + json-patch? Is it on a success path to becoming an industry standard for partial updates over HTTP? 

Best regards,
Szymon Bochniak 

[Jørn Wildt]

I do not know if json-patch has any widespread use, but we use in our API for documents and records handling. Its an internal API, so I cannot show it here, but you can find my initial learnings here: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html. In our API it is more or less possible to PATCH any property returned from the API - with, of course, proper checks for a bunch of internal business rules.

JSON-patch has certain benefits and what I like most is that it makes it very explicit whether you are setting a property to NULL or simply not touching it.

But JSON-patch is also very document oriented and many of the patch operators (like for instance removing a property) are not applicable to a "business data" API.

There is also a couple of problems with JSON-patch:

1) You cannot supply parameters for "side effects" like for instance a log-statement you want to associate with an operation where you update a specific property.

2) If you want to clear an array of items then its not clear if you should set the array to null, assign an empty list, use the array operators or remove the property. There are more possibilities than needed.

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Guille Carlos]

I also use json-patch for one of my projects. Cant complain so far. 

Wanted to share this also just in case you didn't know about it.

https://github.com/json-patch/json-patch2

[Darrel Miller]

I implemented a json-patch library for .net
(https://github.com/tavis-software/Tavis.JsonPatch). I haven't used
it much but it seems like a valid approach to me.

Darrel

[Darrel Miller]

You might also want to take a look at this alternative
http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-07

[Szymon Bochniak]

Thanks for all replies, 

@Jørn - the two problems you wrote about would not affect me in any way. I wanted to restrict the json-patch syntax for my api (my APIs profile for json-patch) to make sure that updates are consistent and aligned with application restrictions:

* forbid test, move and copy operations 
* allow 'add' and 'remove' only for 'paths' pointing to collections (kind of a batch'able replacement for POST and DELETE on collection resources) 

* allow 'replace' for scalar attributes only

@Guille - I haven't seen the json-patch2 discussions yet, great to know it exists. Thanks!

@Darrel - thanks for showing the alternative - i feel though, that operation based patch is a better match in my case.

 

Szymon