CRUD vs REST: How the Two Actually Relate

A user clicks "cancel booking" on a travel site. The browser sends one line over the wire: DELETE /api/bookings/8842. By the time that request lands, it has crossed two different worlds. The first is REST, the style that shaped the HTTP request. The second is CRUD, the database delete that actually removes the row. Same action, two layers, two vocabularies.

CRUD vs REST is a confusing comparison because the two are not competitors. CRUD (Create, Read, Update, Delete) is the set of four operations a data store performs on records. REST (Representational State Transfer) is an architectural style for building web APIs that talk over HTTP. One describes what happens to data at rest; the other describes how a client and server exchange requests over a network. A REST API frequently exposes CRUD operations, but the two solve different problems at different layers.

This guide defines each one, maps the HTTP methods to the CRUD verbs, lays them side by side, and shows where they overlap and where they genuinely diverge. It is written for the people who watch this traffic: SOC analysts and detection engineers who see POST and DELETE calls in access logs long before they see the SQL underneath, and who need to know which layer an alert is describing.

What is CRUD?

CRUD stands for Create, Read, Update, and Delete: the four basic operations any persistent data store supports. The term predates the web. It describes how an application manipulates stored records, whether the store is a relational database like PostgreSQL or SQL Server, or a NoSQL system like MongoDB or DynamoDB.

The four operations map cleanly to SQL statements:

• Create adds a new record. SQL: INSERT.
• Read retrieves records matching some criteria. SQL: SELECT.
• Update modifies an existing record. SQL: UPDATE.
• Delete removes a record. SQL: DELETE.

NoSQL stores expose the same four ideas under different names. MongoDB, for example, uses methods like insertOne(), find(), updateMany(), and deleteOne(). The labels change; the operations do not. CRUD is a vocabulary for talking about data manipulation independent of any specific engine.

CRUD is not a protocol, a product, or a network concept. It is a description of what an application does to data, executed against the database over whatever driver and port that engine uses. It says nothing about how a remote client reaches the application in the first place. That gap is where REST comes in. This article focuses on how CRUD relates to REST; for the operation set on its own, see the dedicated CRUD entry.

What is REST?

REST, Representational State Transfer, is an architectural style for building APIs that communicate over HTTP. Roy Fielding defined it in his <a href="https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">2000 doctoral dissertation</a>, "Architectural Styles and the Design of Network-based Software Architectures." It is not a standard you implement or a library you install. It is a set of constraints an API can choose to follow, and an API that follows them is called RESTful.

Fielding's REST defines six guiding constraints:

• Uniform interface. Resources are identified by URLs and manipulated through a consistent set of methods, so a client interacts with any resource the same way.
• Client-server separation. The client and the server evolve independently as long as the interface between them holds.
• Stateless operations. Each request carries everything the server needs to process it; the server stores no client session state between requests.
• Cacheable responses. Responses declare whether they can be cached, so clients and intermediaries can reuse them.
• Layered system. A client cannot tell whether it is talking to the origin server or to an intermediary like a load balancer or proxy.
• Code on demand (optional). The server may send executable code, such as a script, for the client to run. This is the only optional constraint.

REST operates at the network layer, over HTTP and HTTPS, on ports 80 and 443. It is concerned with how a client addresses a resource, what method it uses, and what status the server returns. It does not care what database sits behind the API, or whether there is a database at all. A REST endpoint can run a calculation, call another service, or trigger a workflow that never touches stored data. CRUD is one thing REST commonly does, not the limit of what it can do. For where REST APIs sit in the broader attack surface, see API security.

How HTTP methods map to CRUD

The reason CRUD and REST get conflated is that the mapping between them is tidy. A RESTful API exposes CRUD operations through standard HTTP methods, and the correspondence is close to one-to-one:

PUT replaces an entire resource; PATCH modifies part of it. Both land on the database as an UPDATE, which is why the four CRUD verbs spread across five HTTP methods. The flow is layered: the HTTP method names the intent at the network edge, the API translates it into a database operation, and the database executes it as SQL or its NoSQL equivalent.

Walk it end to end. A travel site frontend issues GET /api/flights?to=LIS. The REST API receives the call and runs a SELECT against the flight table. The database returns rows, the API serializes them to JSON, and the client gets 200 OK with a list of flights. The user books one with POST /api/bookings, which the API turns into an INSERT. The REST layer is the request and response over HTTP; the CRUD layer is what happens to the data once the request is inside.

CRUD vs REST: the comparison

Both involve a request and a response that ends in success or failure. That is where the resemblance stops. Read the table top to bottom and the split is consistent: CRUD lives at the data layer, REST at the network layer.

The key asymmetry is scope. CRUD is bounded: there are four operations and a limited number of database engines that run them. REST is open-ended: any application can publish a REST API, and an endpoint can do far more than read and write rows. Most REST APIs do expose CRUD because most applications store data, but the style does not require it.

Where they overlap, and where they differ

The overlap is the request-response shape. Both CRUD and REST take an instruction, act on it, and report back whether it worked. A REST call returns an HTTP status code; a database operation returns an engine-specific code. 200 OK and 404 Not Found are the REST-layer equivalents of a database confirming a row was written or reporting that nothing matched. Because the four HTTP write methods line up so neatly with the four CRUD verbs, a developer can reasonably think of a CRUD-backed REST API as one continuous action.

The differences are structural, not cosmetic.

Layer and protocol. REST runs over HTTP on ports 80 and 443, reachable across a network. CRUD runs against the database over that engine's own driver and port, usually inside the trust boundary. A DELETE /api/bookings/8842 and the DELETE FROM bookings WHERE id=8842 it triggers are two events on two systems, captured in two different logs.

Scope of action. CRUD only touches stored records. REST can expose anything: a search that fans out to three services, a payment authorization, a health check that touches no data. When a REST endpoint is not CRUD-backed, there is no SQL underneath at all.

Boundedness. Database engines are a finite, well-known set. REST APIs are effectively unlimited, one per application, each with its own resource model. This is why the comparison feels lopsided: CRUD is a closed vocabulary, REST is an open architectural pattern.

What an analyst sees. This is the practical payoff. A SOC analyst reading API access logs sees the REST layer: method, path, status code, source IP, timing. They do not see the CRUD operation directly. A burst of DELETE calls against /api/bookings is a REST-layer signal that maps to a wave of database deletes, but the analyst is reasoning from HTTP, not SQL. Knowing the mapping is what lets them infer the data-layer impact from the network-layer evidence. The same separation governs who is allowed to make the call in the first place: a REST API enforces access control at the request, while the database enforces its own permissions on the CRUD operation underneath.

Why this matters for monitoring and detection

CRUD vs REST is not just an API design question. It defines where your evidence lives.

When something goes wrong with data, the visible artifact is almost always the REST request, not the CRUD operation. API gateways, web servers, and reverse proxies log the HTTP method, path, status, and source. The database logs the SQL, but those logs are often sparser, harder to attribute to a user, and not always shipped to the same place. A detection program that pulls API logs into log analysis and a SIEM is reasoning at the REST layer, then inferring the CRUD impact.

That inference is where the mapping earns its keep:

• A spike in POST calls to an account-creation endpoint maps to a flood of INSERT operations, the REST-layer fingerprint of automated account creation.
• A run of GET requests walking sequential IDs (/api/users/1, /2, /3) maps to a SELECT sweep, the signature of scraping or enumeration.
• A DELETE storm against a resource maps to bulk row removal, potentially destructive action or ransomware-adjacent behavior.
• A surge of 4xx and 5xx status codes signals failing or malformed operations, often the noise of an attack probing for what works.

None of these read as SQL in the logs. They read as HTTP. Translating the REST-layer pattern into its CRUD-layer consequence is exactly the skill that lets a defender say what an attacker is doing to the data, from evidence that only ever names the API.

Frequently Asked Questions

Is CRUD the same as REST?

No. CRUD is a set of four data operations (Create, Read, Update, Delete) that an application performs against a database. REST is an architectural style for web APIs that communicate over HTTP. They are different layers: CRUD describes what happens to stored data, REST describes how a client and server exchange requests. A REST API often exposes CRUD operations, but the two are not the same thing.

How do HTTP methods map to CRUD operations?

In a RESTful API, POST creates a resource (database INSERT), GET reads one (SELECT), PUT and PATCH update one fully or partially (UPDATE), and DELETE removes one (DELETE). The four CRUD verbs spread across five HTTP methods because REST splits update into full replacement (PUT) and partial modification (PATCH).

Can a REST API do more than CRUD?

Yes. REST is not limited to data operations. A REST endpoint can run a search across multiple services, authorize a payment, trigger a workflow, or perform a health check that touches no database at all. CRUD is the most common thing REST APIs expose because most applications store data, but the style does not require a database behind every endpoint.

What does REST stand for, and who defined it?

REST stands for Representational State Transfer. Roy Fielding defined it in his 2000 doctoral dissertation, "Architectural Styles and the Design of Network-based Software Architectures." It is a style built on six constraints, uniform interface, client-server separation, statelessness, cacheability, layered system, and the optional code on demand, not a standard or a library.

Why does CRUD vs REST matter for security monitoring?

Because evidence lives at the REST layer. API gateways and web servers log HTTP methods, paths, and status codes, not the SQL underneath. An analyst sees POST, GET, and DELETE traffic and has to infer the data-layer impact. Knowing the CRUD mapping lets a defender read a DELETE storm or a sequential GET sweep as bulk deletion or enumeration, translating network-layer evidence into data-layer consequence.

Do CRUD and REST use the same status codes?

No. REST uses HTTP status codes: 200 OK, 201 Created, 404 Not Found, 500 Internal Server Error. Databases return engine-specific response and error codes for their CRUD operations. The REST status code is the outer signal an API client and a log analyst see; the database code is the inner result, visible only in database logs if they are captured at all.

The bottom line

CRUD and REST are not rivals. CRUD is four operations on stored data: Create, Read, Update, Delete, executed as INSERT, SELECT, UPDATE, DELETE against a database. REST is an architectural style for web APIs over HTTP, defined by Fielding's six constraints, that frequently exposes those CRUD operations through POST, GET, PUT, PATCH, and DELETE. One is the data layer, the other is the network layer, and a single user action usually crosses both.

For a defender, the split is the point. The logs you collect almost always capture the REST request, not the CRUD operation it triggers. Reading the HTTP method and inferring the database impact, a POST flood as mass record creation, a DELETE storm as bulk deletion, is how you turn API-layer evidence into a statement about what an attacker did to the data.