<p>I’ve been thinking about the PATCH route in the API we made last week. In truth it was not really a PATCH but a PUT, because we had coded it so it gave an error unless you sent in the body ALL the key value pairs for the entry. I sat down to try to work out a logic for a proper patch, ie a route where you can send updated values for only those keys where you wish to change the values, and the others would be left unchanged. But I ended up wondering what I ought to do if the data sent in the request includes keys that aren’t currently in the object. Should they be added? (Seems dangerous to allow users of the API to be adding columns to our tables??) Or should those parts be rejected but any entries with keys that match existing keys updated? Or should the whole request be rejected because we deem it malformed?</p>
<p>I guess there is a bigger issue here about needing to define what constitutes a valid and invalid object in the database, which presumably one does at some global level with some sort of schema rules? We haven’t learnt this yet. So probably this is two questions: (1) where and how does one define validity for an entry, and (2) how “kind” should one be when requests can’t be fully executed because they would break this validity - should we perform as much of them as we can, or just do a “computer says no”?</p>


I’ve been thinking about the PATCH route in the API we made last week. In truth it was not really a PATCH but a PUT, because we had coded it so it gave an error unless you sent in the body ALL the key value pairs for the entry. I sat down to try to work out a logic for a proper patch, ie a route where you can send updated values for only those keys where you wish to change the values, and the others would be left unchanged. But I ended up wondering what I ought to do if the data sent in the request includes keys that aren’t currently in the object. Should they be added? (Seems dangerous to allow users of the API to be adding columns to our tables??) Or should those parts be rejected but any entries with keys that match existing keys updated? Or should the whole request be rejected because we deem it malformed?

I guess there is a bigger issue here about needing to define what constitutes a valid and invalid object in the database, which presumably one does at some global level with some sort of schema rules? We haven’t learnt this yet. So probably this is two questions: (1) where and how does one define validity for an entry, and (2) how “kind” should one be when requests can’t be fully executed because they would break this validity - should we perform as much of them as we can, or just do a “computer says no”?

Day 25: Contemplating database philosophy