PATCH is a nightmare in reality, especially with the default zero nature of Go.

We opted for the JSON PATCH notation in RFC 6902: http://tools.ietf.org/html/rfc6902

Essentially there's a standard format for instructions on how to modify an existing JSON document, like this:

   PATCH /my/data HTTP/1.1
   Host: example.org
   Content-Length: 326
   Content-Type: application/json-patch+json
   If-Match: "abc123"

   [
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]

We've implemented the operations "add", "remove" and "replace" in our REST API.

We don't have a meaningful way of doing "move" and "copy", and "test" can be done by performing a GET and looking at the document (and that can be used in the If-Match).

You can see the documentation for our stuff here: http://microcosm-cc.github.io/#events-single-patch

And that gives away why we chose to do this... booleans and the default value of false. We wanted it to be more explicit and no room for accidental expression of a value anywhere, regardless of the callee language/environment or ours. JSON PATCH makes this very explicit.

Of course there's the mild inconvenience of handling the value type, but that's relatively easily overcome.

What was really interesting was handling permissions for the PATCH instructions.

For example a user might have permission to issue a PATCH that changed a string, but only the admin could issue a PATCH that updated some special part of a resource.

PATCH is relatively easy with the above, and very predictable... fine-grained permissions of which part of a document someone can update... that's definitely where the fun is.