Is it a common pattern to put create/update/archive as one process?

Question

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].

For example:

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)

Answer 1

The delete/archive combo is not so foreign. Most OS's allow you to delete files, which puts them in the "trash." They are not truly deleted at that point, but navigating to the folder in which it used to reside will not show the file. Functionally the file is deleted. The fact it is in the trash is an implementation detail that isn't important to the user.

So a request to DELETE /items/5 sets an archive flag. It is technically an update, but if a subsequent request to GET /items/5 returns a 404 Not Found then functionally it has been deleted from the perspective of the client. The fact an archive flag gets set is an implementation detail the client is not concerned with.

If a request to PATCH /items/5 (or POST) means a subsequent request to GET /items/5 returns a 404 Not Found then I would be pretty surprised. I would think that a bug exists in the service. If after flipping the archive flag a request to GET /items/5 returns the item with the archive flag flipped then, that feels a little more natural.

So the answer to your question depends on the expected response to a subsequent GET. If you get a 404 response then use a DELETE. If the resource will be returned with a subsequent GET then a PUT or PATCH to flip the archive flag is appropriate.