REpresentational State Transfer—or REST—is an architectural style for creating APIs that communicate over the HTTP protocol.

Behind the scenes, APIs often need to manipulate data as part of their operation. Typically, these data operations—called CRUD for short—run against backend databases. CRUD stands for Create, Read, Update, and Delete, which make up these four fundamental operations.

Because REST API calls invoke CRUD operations, understanding their relationship with one another is important for API developers and data engineers. Although CRUD and REST serve different purposes, one shouldn’t negatively impact the performance of the other.

In this article, we will introduce CRUD and REST, explain their similarities and differences, and then consider how to best monitor their performance.

What is CRUD?

CRUD operations apply to traditional relational database management systems (such as PostgreSQL or SQL Server) and the more recent NoSQL databases (such as MongoDB or DynamoDB). Although file-oriented operations also manage information manipulation, CRUD generally refers to record-oriented operations in computer databases.

In relational database management systems (RDBMS), a database table row is referred to as a record, while columns are called attributes or fields. Let’s look at the four CRUD operations one by one.

Create

A create operation adds a new database record. The SQL equivalent for this operation isINSERT.

Read

A read operation retrieves records (or documents or items, depending on the database type) from a database table (or collection) based on search criteria. The SQL equivalent of a read operation is SELECT. Read operations can return a subset of records and fields depending on the query.

Update

An update operation, which is alsoUPDATEin SQL, changes existing records in a database. An update operation, like read, can affect all or a subset of records and/or fields.

Delete

A delete operation, which is also DELETE in SQL, removes one or more records from the database.

In NoSQL databases, the expressions that correspond to CRUD operations depend on the platform, data structures, and language. For example, in MongoDB:

• A create operation uses db.collection.insertOne() or db.collection.insertMany().
• A read operation uses db.collection.find() or db.collection.findOne().
• An update operation uses db.collection.updateOne(), db.collection.updateMany(), or db.collection.replaceOne().
• A delete operation uses db.collection.deleteOne() or db.collection.deleteMany().

Typically, the API application code carries out CRUD operations by invoking stored procedures, functions, or triggers in the RDBMS. Sometimes, API code can also pass dynamically-generated SQL commands to the database engine.

In NoSQL databases, the API application code sends the commands via the database driver. For example, a Java application may call the HBase driver library to send CRUD commands to the database. Behind the scenes, the driver will translate the commands from Java and run them on the database.

Real-world example of CRUD

Let’s consider a real-world example of CRUD in action. When a user books a trip through an online travel service app, the application creates a reservation record, reads available hotel and room information, updates the list of available rooms when a reservation is confirmed, or deletes the entire reservation record if the user cancels the request. Similar operations happen in any transaction-processing application.

What is REST?

REST is an architectural style for APIs often used in distributed applications. REST (or RESTful) APIs are applications that adhere to REST architecture principles and allow client applications and other APIs to interact with them via their API endpoints. Applications accessing RESTful APIs typically send their requests using HTTP protocol methods. The six guiding constraints of REST are:

1. Uniform interface: The uniform interface allows any API client to communicate with the server in a consistent, standardized manner, regardless of the client or the server’s programming language or implementation.
2. Client-server: The client-server design pattern stipulates separate roles for the client and the API server. The server is responsible for backend functionality like data storage, validation, and authentication. Meanwhile, the client deals with user interface, query building, and so on.
3. Stateless: To be stateless, each client request to the API must contain all the information necessary for the server to carry out the task. The server doesn’t save any session state information about either the client or the server. As far as the API is concerned, each client request is a new one, separate from the previous request.
4. Cacheable: The cacheable constraint dictates that the response from the API determines whether the client is allowed to cache the API’s response. The API marks the response as cacheable or non-cacheable.
5. Layered system: Layering refers to the inclusion of optional components providing functionality. Examples can be load-balancing, validation, and so on. Such layers must be transparent to the client. Components in each layer must not be able to see anything other than the layer they are working with.
6. Code on demand (optional): Code on demand allows clients to download and run code from the API server.

REST APIs are prevalent in modern applications. For example, weather APIs, video streaming services, social media, or ride-sharing applications extensively use REST APIs.

HTTP Methods

Clients wrap RESTful API requests using HTTP methods:

• GET: The GET request asks the API to retrieve a resource, such as a database record or the contents of a file, and send it to the client.
• POST: With the POST method, the client sends data to the API server, which creates a resource with the supplied data.
• PUT: When the client sends a PUT request to the API, it points to the URI of a specific resource and provides data in the request body. When the API server receives the PUT request, it checks if the resource already exists. If the resource exists, then the API updates the resource with the data enclosed in the PUT request. If the resource doesn’t exist, then the API creates that resource with the data supplied.
• PATCH: The client sends a PATCH request to the API to partially update an existing resource.
• DELETE: The client sends a DELETE request to an API to delete an existing resource.

Example REST API requests

Several client tools can send requests to API endpoints. A common command-line tool is cURL. Below are some examples of using cURL to send HTTP requests to a fictitious REST API endpoint.

The endpoint for our fictitious REST API is http://www.foobar.com, and we are sending different HTTP requests to this API to create, read, update, or delete customer records.

In this following code snippet, the cURL client asks for details of a customer with customer ID 19. This is a GET request.

curl -v http://www.foobar.com/find_customert_record?id=19

Next, we add a customer record with a POST request. In the following example command, we enclose the data in the body of the HTTP request.

curl -X POST -d 'id=10&customer_name=joe_bloggs' http://www.foobar.com/add_customer_record

In this example, we point to a file that contains the data for the record creation.

curl -X POST -d @customer_record.json -H "Content-Type: application/json" http://www.foobar.com/add_customer_record

To update the customer record, we send the following PUT requests.

curl -d 'id=10&client_name=jane_bloggs' -X PUT http://www.foobar.com/update_customer_record

And finally, we remove the customer with customer ID 22:

curl -X DELETE http://www.foobar.com/delete_customer_record?id=22

CRUD vs REST: Similarities and Differences

As you can see, despite their differences, RESTful API operations can be very similar to database CRUD operations:

In the online travel service app example mentioned above, a web application initiates the create, read, update, and delete CRUD operations. The frontend website will make REST API calls, the API code will then translate these requests to database CRUD commands and pass those on to the database driver. Once the database driver sends a response back (successful or unsuccessful), the API code will translate that to an HTTP response and send it to the client.

For both REST and CRUD, a response is sent to the requesting party. For REST API clients, this comes in the form of a standard HTTP response (for example, 200 OK, 404 Resource Not Found, 500 Internal Server Error). For CRUD, each database engine will have its own response codes for success, failure, or warnings.

Now, let’s consider the differences.

We have already mentioned how CRUD and REST work in different parts of an application stack. REST APIs accept their payloads over the HTTP protocol, while CRUD uses whatever protocol the database has enabled. The network packets have different structures as well. Typically, REST APIs accept client requests over port 80or 443, though this is configurable. For CRUD operations, the database server configuration stipulates the port. For example, the default port for SQL Server is 1433.

CRUD functions can exist inside the REST API code. However, REST APIs are not limited to invoking only CRUD operations. REST APIs can invoke other functions, subroutines, and even other APIs.

While there are countless REST APIs (public and private), only a finite number of database engines (including RDBMS, NoSQL, and in-memory databases) are available today.

Discover the world’s leading AI-native platform for next-gen SIEM and log management

Elevate your cybersecurity with the CrowdStrike Falcon^® platform, the premier AI-native platform for SIEM and log management. Experience security logging at a petabyte scale, choosing between cloud-native or self-hosted deployment options. Log your data with a powerful, index-free architecture, without bottlenecks, allowing threat hunting with over 1 PB of data ingestion per day. Ensure real-time search capabilities to outpace adversaries, achieving sub-second latency for complex queries. Benefit from 360-degree visibility, consolidating data to break down silos and enabling security, IT, and DevOps teams to hunt threats, monitor performance, and ensure compliance seamlessly across 3 billion events in less than 1 second.