1. 10
  1. 3

    I very much like this approach, it makes removal of elements via PATCH straight-forward.

    1. 2

      JSON-Patch is very good approach. On the other hand, the Merge-Patch proposal could be adequate for some documents and way simpler to implement on both sides.


      {"email": "someone@example.com", "jabber": null}

      It’s only drawback is the requirement for target document to never naturally contain nulls.

      1. 2

        While I think the API you put forward should obviously depend on your needs, I do think it’s great to make sure people know that the PATCH action is in their toolbelt, as well as JSON-Patch as a way of expressing changes.

        I do wish the author had stressed using the “test” op more strongly. Putting some sort of state assertion like timestamp or oldval checking as well as exception handling for it into your transaction is something just as important if you’re taking a serious look at PATCH. It is just an overview with plenty of links to more details though.

        1. 1

          I think the na├»ve way is fine, since it’s minimal and stupid instructions for update. Not good ones, but instructions none the less through the right lens.

          However, you really do get a lot out of fine-grained instructions like that. Idempotency even for more complex situations, conditional update. Good stuff.