CRUD and REST, two prominent concepts in the API industry, are often confused. Whereas REST is one of the most popular design styles for web APIs (among other applications), CRUD is simply an acronym used to refer to four basic operations that can be performed on database applications: Create, Read, Update, and Delete.

As we’ll see in this article, there is indeed some overlap between CRUD and REST. The confusion lies in the fact that it isn’t as quite extensive as many think, though…

What Is CRUD?

Create, Read, Update, and Delete — or CRUD — are the four major functions used to interact with database applications. The acronym is popular among programmers, as it provides a quick reminder of what data manipulation functions are needed for an application to feel complete.

Many programming languages and protocols have their own equivalent of CRUD, often with slight variations in how the functions are named and what they do. For example, SQL — a popular language for interacting with databases — calls the four functions Insert, Select, Update, and Delete. With a little nudging, CRUD also maps to the major HTTP methods — a topic we’ll come back to later.

Functions

Although there are numerous definitions for each of the CRUD functions, the basic idea is that they accomplish the following in a collection of data:

What Is REST?

On the other hand, Representational State Transfer — or REST — is a popular architectural style for software, especially web APIs. It’s defined by five design constraints that, when followed, produce an application with specific properties, including performance, simplicity, and reliability.

Constraints

The five basic constraints that define a REST application are:

1. Client-Server: The client and server act independently.
2. Stateless: The server does not record the state of the client.
3. Cacheable: The server marks whether data is cacheable.
4. Uniform Interface: The client and server interact in a uniform and predictable way. An important aspect of this is that the server exposes resources.
5. Layered System: The application behaves the same regardless of any intermediaries between the client and server.

It’s okay if you don’t know what all of these constraints mean. What’s important is that you know they exist, so that you can understand the overlap between CRUD and REST.

CRUD vs REST Explained

The confusion between CRUD and REST stems from the fact that interacting with REST applications often involves the use of CRUD-like functions. This is because REST applications are built around resources (as outlined in the Uniform Interface constraint), which can be created, read, updated, and deleted, just like entries in a collection of data.

Let’s dive a little deeper. Most of the time, when we talk about REST, we refer to web APIs that adhere to the constraints of REST — or REST APIs. By the nature of REST APIs being served over the web, these APIs communicate with clients using the HTTP protocol, which has its own set of methods for data manipulation: GET, POST, DELETE, PUT, and PATCH, among others. And if you think about it, there’s clearly some overlap between HTTP methods and CRUD functions:

Indeed, these methods and functions are roughly equivalent, which is why we often hear about CRUD in the context of REST. However, they don’t quite map one-to-one:

• PUT replaces a resource (even if that resource doesn’t yet exist), while POST usually adds a new resource. They can both be used to Create new resources, but PUT is mainly used to Update existing resources.
• PATCH is used to Update part of a resource, whereas PUT is only used to Update an entire resource (by replacing it).
• POST is processed “according to the resource’s own specific semantics” (per the RFC), making it something of a catch-all. It can even have Update functionality, like when sent to an /updates/ subresource.

For some, however, the real kicker is that REST APIs aren’t limited to CRUD functions. For example, a REST API can still allow clients to reboot a server — even though that doesn’t equate to any of the four CRUD functions — as long as it involves the use of appropriate HTTP methods.

“As long as the method is being used according to its own definition, REST doesn’t have much to say about it.” – Roy Fielding

More Examples of REST and CRUD

To understand the nuances more clearly, let’s look at how common HTTP methods are used in RESTful web APIs. For example, to create an image with the OpenAI image generation API, you would send a POST HTTP call to https://api.openai.com/v1/images/generations. Yet, if you were simply retrieving a set of files, you would send a GET request to https://api.openai.com/v1/files. These actions generally correspond to CREATE and READ in CRUD.

Now, let’s consider what CRUD operations look like using a popular database architecture. In PostgreSQL, for instance, the CREATE TABLE command is synonymous with CREATE in CRUD. PostgreSQL also has UPDATE and DELETE commands, just like CRUD. However, instead of READ, PostgreSQL adopts the SELECT command to read entries from a database. The syntax for SELECT in PostgreSQL will look something like: SELECT select_list FROM table_name;.

Summary

Create, Read, Update, and Delete — CRUD — are the four major functions for interacting with database applications. CRUD functions often play a role in web-based REST APIs, where they map (albeit poorly) to the HTTP methods GET, POST, DELETE, PUT, and PATCH. Importantly, REST APIs can still expose functionality not corresponding to CRUD, so long as they use the appropriate HTTP method.