EMZETT.CRUD
In short: The four basic data operations: Create, Read, Update, Delete.
In more detail: Practically every application that holds data implements these four operations somewhere — whether as database commands (INSERT, SELECT, UPDATE, DELETE in SQL) or as REST endpoints (POST, GET, PUT/PATCH, DELETE). Serves as shared vocabulary for talking about a system’s basic functionality.
In Depth
The four CRUD operations map onto almost every layer of an application in a similar way, just with different vocabulary:
| CRUD | SQL | REST/HTTP |
|---|---|---|
| Create | INSERT | POST |
| Read | SELECT | GET |
| Update | UPDATE | PUT/PATCH |
| Delete | DELETE | DELETE |
In REST, PUT typically replaces an entire resource, PATCH only changes individual fields — this distinction isn’t always cleanly followed in practice. A “CRUD interface” or “CRUD screen” is a common term in application development for a simple management interface that essentially only offers these four operations on a database table — many admin panels (e.g. the one Django automatically generates) are, at their core, nothing else.
In practice, a variant is often added for sensitive data: instead of a real delete, only a flag is set (“soft delete”), so data doesn’t immediately disappear irrevocably, for traceability or legal reasons (e.g. GDPR).
CRUD as a starting point, not an endpoint
CRUD operations cover the basic functionality, but real applications almost always need additional, more domain-specific operations that don’t fit cleanly into this scheme — e.g. “cancel order” (more than a simple update, often triggers further processes like a refund) or “reset password” (not a Create/Update in the classic sense, but its own, multi-step flow). A purely CRUD-based API design (“CRUDy API”) is therefore sometimes seen as a warning sign of a too-simple domain model that doesn’t capture the actual business logic, but merely passes database access straight through.
Idempotency
An important technical detail: according to the HTTP specification, PUT and DELETE should be idempotent — a repeated, identical call should produce the same end state as a single call (e.g. “delete resource X” twice in a row leads to the same result as once). POST (Create), by contrast, is deliberately NOT idempotent — two identical POST requests typically create two new resources, which can lead to unwanted duplicates with network errors and automatic retries, if this distinction isn’t taken into account.