Based on #Indieweb #Micropub experience, #CRUD is an anachronism. Need undelete+incrementalism: #CDURU See: Wikipedia’s CRUD article https://en.wikipedia.org/wiki/CRUD says: "Without at least these four operations, the software cannot be considered complete." This has been empirically disproven, at least by any practical meaning of "complete" (AKA useful & used) for several subsets: 1. Create only 2. Create + Delete 3. Create + Delete + Undelete 4. Create Delete Undelete Read Update (CDURU) Create only: Numerous Micropub http://micropub.net/draft/ implementations have demonstrated that create-only is both useful and just fine on its own without ever implementing anything else. SMS, specifically the act of texting, is another popular create-only interface that has wide adoption. Once you have sent a text, there is no deleting it (a local delete has no effect on the copy the recipient has received). Create + Delete only: Twitter proved that create + delete as the only operations you can do with tweets was sufficiently useful (complete) for mass adoption. No need for updates for something to be “complete” from the perspective of useful, actually used, used frequently, and repeatedly over time. People keep asking for editing tweets, but keep using Twitter anyway — a good example of the far greater importance of observing and paying more attention to what users do, than what they say (want/demand/ask/etc.). Add Undelete: The next logical operation is not read nor update, but rather, undelete. This is true both from a user perspective (oops, I didn’t mean to delete that! Undelete!), and from an implementation perspective (implementing undelete and ensuring that all user-state / content has been restored is a good way of double-checking your delete implementation as well). Undelete and the broader notion of Undo have been in user interfaces since the 1980s (at least, widespread multiple undo since 1990s). https://en.wikipedia.org/wiki/Undelete https://en.wikipedia.org/wiki/Undo Various social media sites (silos, e.g. Facebook) implemented undelete (like of status posts, perhaps as Undo Delete, or Restore) long before they implemented "Edit" (update). Being able to even just undelete something that you deleted was useful all on its own, without any comprehensive editing/updating capabilities. Reads and Updates Read as an operation refers specifically to reading previously created content from a service, which, while potentially useful for an API, is often either unnecessary or implicit in being able to view, load, parse someones recent posts, or stream of updates (e.g. the h-entry and possibly h-feed @microformats markup on an indieweb site home page). http://microformats.org/wiki/h-entry http://microformats.org/wiki/h-feed Read becomes necessary when you want to implement Update, in particular if you only want to implement updating of specific aspects of a post. For example if your client was implementing tagging a post, your client must implement first reading the existing tags on the post to show them to the user (so they don't errantly waste time re-adding existing tags). Once your implementation can read existing tags, then it can implementing updating those tags by either just adding to them, or removing some (if the user deleted a few), or replacing the full set of tags (if the user added and deleted some). It’s worth distinguishing these add/remove/replace use-cases even for simple strings for the same reasons it is useful to distinguish create/delete/update of entire posts, e.g. you might grant different add vs remove/replace permissions to different clients. Thus if you’re implementing a client-server interaction (e.g. Micropub), it makes sense, is possible, and incrementally useful to you and your users to implement in this order: Create Delete Undelete Read Update CDURU - pronounced kuh-doo-roo. (Feedback from Micropub implementers welcome to confirm/dispute/improve any of the above!)

Based on #Indieweb #Micropub experience, #CRUD is an anachronism.
Need undelete+incrementalism: #CDURU

See: Wikipedia’s CRUD article https://en.wikipedia.org/wiki/CRUD says:

"Without at least these four operations, the software cannot be considered complete."

This has been empirically disproven, at least by any practical meaning of "complete" (AKA useful & used) for several subsets:

1. Create only
2. Create + Delete
3. Create + Delete + Undelete
4. Create Delete Undelete Read Update (CDURU)

Create only: Numerous Micropub http://micropub.net/draft/ implementations have demonstrated that create-only is both useful and just fine on its own without ever implementing anything else.

SMS, specifically the act of texting, is another popular create-only interface that has wide adoption. Once you have sent a text, there is no deleting it (a local delete has no effect on the copy the recipient has received).

Create + Delete only: Twitter proved that create + delete as the only operations you can do with tweets was sufficiently useful (complete) for mass adoption.

No need for updates for something to be “complete” from the perspective of useful, actually used, used frequently, and repeatedly over time.

People keep asking for editing tweets, but keep using Twitter anyway — a good example of the far greater importance of observing and paying more attention to what users do, than what they say (want/demand/ask/etc.).

Add Undelete: The next logical operation is not read nor update, but rather, undelete.

This is true both from a user perspective (oops, I didn’t mean to delete that! Undelete!), and from an implementation perspective (implementing undelete and ensuring that all user-state / content has been restored is a good way of double-checking your delete implementation as well).

Undelete and the broader notion of Undo have been in user interfaces since the 1980s (at least, widespread multiple undo since 1990s).

https://en.wikipedia.org/wiki/Undelete
https://en.wikipedia.org/wiki/Undo

Various social media sites (silos, e.g. Facebook) implemented undelete (like of status posts, perhaps as Undo Delete, or Restore) long before they implemented "Edit" (update).

Being able to even just undelete something that you deleted was useful all on its own, without any comprehensive editing/updating capabilities.

Reads and Updates

Read as an operation refers specifically to reading previously created content from a service, which, while potentially useful for an API, is often either unnecessary or implicit in being able to view, load, parse someones recent posts, or stream of updates (e.g. the h-entry and possibly h-feed @microformats markup on an indieweb site home page).

http://microformats.org/wiki/h-entry
http://microformats.org/wiki/h-feed

Read becomes necessary when you want to implement Update, in particular if you only want to implement updating of specific aspects of a post.

For example if your client was implementing tagging a post, your client must implement first reading the existing tags on the post to show them to the user (so they don't errantly waste time re-adding existing tags).

Once your implementation can read existing tags, then it can implementing updating those tags by either just adding to them, or removing some (if the user deleted a few), or replacing the full set of tags (if the user added and deleted some). It’s worth distinguishing these add/remove/replace use-cases even for simple strings for the same reasons it is useful to distinguish create/delete/update of entire posts, e.g. you might grant different add vs remove/replace permissions to different clients.

Thus if you’re implementing a client-server interaction (e.g. Micropub), it makes sense, is possible, and incrementally useful to you and your users to implement in this order:

Create
Delete
Undelete
Read
Update

CDURU - pronounced kuh-doo-roo.

(Feedback from Micropub implementers welcome to confirm/dispute/improve any of the above!)