Traditionally it's assumed that we should treat create read update delete as separate concepts. However, I have noticed that the following pattern seems more usable for certain contexts [create, update, delete], [read].
In the context where what's allowed for a new object may be virtually indistinguishable from an existing object for many properties
Create or Update. By combining create and update into one step, it creates lots of reuse. This dramatically simplifies backend code to two parts: If no ID is provided create a new object (relatively empty), if an ID is provided attempt to get it. Then perform the update. The front end is also simplified, and from a user interaction perspective new and updates (edits) are automatically consistent.
In some cases, "Delete" is actually "Archive" and acts more like a property update then a separate request, ie turning an "is_archived" flag to True. In this context it becomes a sub set of Update.
What I am already aware of
- REST does not need to be used for internal APIs
- Most things aren't really REST
The goal is not so much to have an all in one end point as is brought up here: RESTful API versus One Do-All Endpoint
But rather to combine like concerns, and make it more composable. For example adding a property in this pattern means adding it one place.
The net effect is instead of having 3 back end routes, and 3 front end components (6 total), there's 1 of teach (2 total), with only marginal differences where required.
Read operations seem significantly different because * In general the object is assumed to always exist * Usually reading multiple objects or doing other things with it. * Often different permission and context assumptions
This is discussed a bit here Is it better to have separate Create and Edit actions or combine Create and Edit into one? And there was some discussion of trade offs.
Key distinction is that I'm not so much asking just for the back end API, but more the way a person thinks about in the context of both Front and Back end, the context of archiving also being a part of it. (And in context of modern frameworks)