In a resource-api, the method of updating partial properties of resources can be used with the METHOD patch. Along that, one of the standard people seem to have chosen is JSON PATCH.

As far as I understand, the JSON PATCH standardize in laying operations to alter the a json object. And many of these JSON PATCH libraries have build around this.

However, what I don't understand is that if I'm just allowing a PATCH endpoint to receive changes on some properties of a 'client facing resource'. How do these libraries that offers to object-mutation actually help? its not like my database being just one giant piece of JSON object. Unless maybe a more specific piece of data, like on my sql table, its usage is to specifically change the column data that typed as JSON. then re-update into the SQL table. In that case, should regular column types still confirm to JSONPATCH, how does it get delegated into database changes?

I feel like, unless its actual json type, updating a resources which is coarse grain require a lot of pruning/validations. i.e.

1. ensure only some rows are editable
2. ensure some operations are only allow
3. map changes into SQL specific tables/columns. because any of the client-facing-resource properties could've structured from join table.

CodePudding user response：

The JSON PATCH format is really document-oriented and it's far more easier to use when working with JSON documents like in MongoDB rather than with traditional SQL databases, however you could still use JSON PATCH with a relational model as well and object-mutation libraries will help here.

For it to work properly you'd need to have at least three additional components in your system - one that converts one or more database tables into a JSON document, one that can validate a JSON document of given format and one that can "translate" a JSON object into database tables aka generates insert/update/delete queries based on the existing data in the database and the JSON document that you got after performing the PATCH. A minimal algorithm for such an endpoint would look like this:

1. The JSON PATCH endpoint gets called.
2. The component responsible for converting database tables to a JSON document is called.
3. Your library applies the operation to that document.
4. The validation component validates the resulting document.
5. The component responsible for translating JSON document to the database is called and runs the appropriate queries

If this sounds like too much of a hassle it's because it actually is, and using a traditional REST approach when dealing with a relational data model is far more easier and straightforward than using JSON PATCH.