HTTP PATCH and JSON PATCH.

This is a part of the 100 Days To Offload challenge.

Of course I find it funny I’m working on APIs as as front-end developer. It might be time to discard the imposter hat slowly and carefully, and come out cleanly as a beginner full-stack developer?

Tomayta, tomahto.

I learned a quick, cool thing today.

HTTP PATCH, to this date, is a Proposed Standard. πŸ™ƒ

Well, that’s one cool thing. Here’s another one…

If your resource is a JSON document, you can’t just send some JSON data that would replace only the given keys in the resource. Well, you can, but you know.

If your resource, after creation, is:

{
"name": "A new name."
}

…and you want to update it; this would be considered invalid:

PATCH /api/v1/articles/1333 HTTP/1.1
Content-Type: application/json

{
"name": "A new name. A new beginning."
}

What you’d do instead is make use of another Proposed Standard, RFC6902: JavaScript Object Notation (JSON) Patch.

So, the “correct” way would be to send a description of the changes using a different Content-Type header and request body:

PATCH /api/v1/articles/1333 HTTP/1.1
Content-Type: application/json-patch+json

[
{
"op": "replace",
"path": "/name",
"value": "A new name. A new beginning."
}
]

We used the replace operation here. Notice that the Content-Type changed too.

There are many more operations – check out the RFC I linked to elsewhere.

Made a mistake? Drop me an email and I’ll correct it.