In computer programming, Create, Read, Update, and Delete (CRUD) are the four basic operations of persistent storage. CRUD is also sometimes used to describe user interface conventions that facilitate viewing, searching, and changing information using computer-based forms and reports. The term was likely first popularized by James Martin in his 1983 book Managing the Data-base environment.
Data can be put in a location/area of a storage mechanism.
Together these four operations make up the basic operations of storage management known as CRUD: Create, Read, Update, and Delete.
Although relational databases are a common persistence layer in software applications, numerous other persistence layers exist. CRUD functionality can for example be implemented with document databases, object databases, XML databases, text files, or binary files.
Note: Some big data systems do not implement UPDATE, but have only a timestamped INSERT (journaling), storing a completely new version of the object each time.
The acronym CRUD also appears in discussion of RESTful APIs. Each letter in the acronym may be mapped to a Hypertext Transfer Protocol (HTTP) method:
In HTTP, the GET (read), PUT (create and update), and DELETE (delete) methods are CRUD operations as they have storage management semantics, meaning that they let user agents directly manipulate the states of target resources. The POST method on the other hand is a process operation that has target-resource-specific semantics excluding the semantics of CRUD operations.
CRUD is also relevant at the user interface level of most applications. For example, in address book software, the basic storage unit is an individual contact entry. As a bare minimum, the software must allow the user to: 
Because these operations are so fundamental, they are often documented and described under one comprehensive heading such as "contact management" or "document management" in general.
Other variations of CRUD include:
POST only becomes an issue when it is used in a situation for which some other method is ideally suited: e.g., retrieval of information that should be a representation of some resource (GET), complete replacement of a representation (PUT), or any of the other standardized methods that tell intermediaries something more valuable than “this may change something.” The other methods are more valuable to intermediaries because they say something about how failures can be automatically handled and how intermediate caches can optimize their behavior. POST does not have those characteristics, but that doesn’t mean we can live without it. POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”
Edited: 2021-06-19 17:55:17