REST vs CRUD

CRUD and REST are two of the most popular concepts in the Application Program Interface (API) industry. REST was made to standardize the HTTP protocol interface between clients and servers and is one of the widely used design styles for web API. On the other hand, CRUD is an acronym used to refer to the four basic operations executed on database applications. Because both work on manipulating databases’ data, it’s easy to see why people have some confusion between them. This blog will discuss what REST and CRUD are, the basic principles that govern them, and their similarities and differences.

What Is REST?
Brief History of REST
The 5 Principles of REST
What Is CRUD?
A Short History of CRUD
CREATE, READ, UPDATE, DELETE: Principles of CRUD
What Are the Similarities Between REST and CRUD?
What Are the Differences Between REST and CRUD?
REST and CRUD Work Together, but They Are Not the Same

What Is REST?

REST is an abbreviation for Representational State Transfer. It is a software architectural style that provides standards for computers on the web, dictating how the systems interact. Roy Fielding, the founder of the REST protocol, defines it as “an abstraction of the architectural elements within a distributed hypermedia system.”

Brief History of REST

Before the launch of the REST protocol in 2000, web developers had no standard of how to develop a web API or even use one. Many protocols were used at that time, but they proved too tedious and complicated to carry out. Together with his colleagues, Roy Fielding sought to address this problem and developed what is known today as the REST protocol. The development of REST allowed two servers to exchange data worldwide.

REST-compliant systems are called RESTful systems. These systems are characterized by their statelessness and the separation of client and server concerns. Since its launch in 2000, many companies such as eBay and Amazon have used the REST protocol.

The 5 Principles of REST

REST has five basic principles that it operates with.

1. Client-Server Mandate

The REST protocol allows for independent implementation for the client and the server. This independence means that both parties can make changes without knowing or interacting with one another. Defining what a server and client are is the first step to understanding this principle.

Server– Simply put, servers are machines that provide services to other devices. There are different types of servers such as boot servers, database servers, print servers, and specialized servers for specific applications. Various applications rely on other applications to deliver a service. For example, a search engine will direct the information to its web server. In contrast, a printer on a network will funnel the information to the printer server to generate a result.
Client– A client is a remote system that uses services from a server. All the machines connected to a server are called clients. Because some clients have limited disk capacity, they rely on remote file systems to function. Some devices can both be a client and a server at the same time.

The REST protocol allows the two systems to work independently of one another without affecting the result. As long as the client and the server know what format to use when sending messages, different clients eventually reach the same REST endpoints. The separation of the client and server interface also allows both systems to evolve independently of one another.

2. Statelessness

RESTful APIs do not cache anything about the HTTP request made on the client side. Not caching means the server treats every session as new and cannot take advantage of any previous information stored on the server. To be genuinely stateless, a server does not store any authentication details of any prior session by the same client. Because a REST API is stateless, a client must provide all the necessary information every session to enable a server to complete a task.

3. Cacheable

Requests on a server go through different pathways or caches. These caches can either be a local cache, proxy cache, or reverse proxy, and a RESTful API’s server can mark information as either cacheable or non-cacheable. When a client requests their end, this request goes through a series of caches. If any caches along that path have a fresh copy of the representation, it uses that cache to generate a result. When none of the caches can fulfill the request, it goes back to the origin server. A RESTful API’s servers determine whether the information is cacheable or non-cacheable.

Caching has several benefits, some of which are:

Reduces bandwidth.
Decrease latency by decreasing the number of trips to and from the server for fetching data from memory.
Reduces server load.
Decreases network failures.

4. Uniform Interface

A system that utilizes the REST API has the client and the server interacting predictably. A resource in the system follows only one logical Uniform Resource Identifier (URI). What differentiates RESTful APIs from non-REST APIs is the uniformity of this interface regardless of the device or application used. Resources on a REST API use Hypermedia as the Engine of Application State (HATEOAS) to fetch related information whenever applicable. All resources on RESTful APIs follow specific guidelines with naming conventions and link formats. A uniform interface follows four guiding principles:

Resource-based- Each resource uses URI as a resource identifier.
Actions on Resources Through Representations- A resource associated with metadata contains information on the server to modify or delete.
Self-descriptive Messages- Each message has all the information to describe how it is processed.
Hypermedia as the Engine of Application State (HATEOAS)– Clients provide states by body content, request headers, and URI, and the service provides customers with the state by response codes, response headers, and body content. This is called Hypermedia.

5. Layered System

A RESTful API relies on a layered system to deliver results. This layered system provides a hierarchy that constrains a layer from seeing beyond the layer that it is assigned to. This layered system allows the developer to deploy various functions to different servers. Each layer works independently, and each layer does not know the functionality of other layers besides its own. On the user end, a layered system does not allow the user to ordinarily differentiate whether they are connected to a primary or intermediary server. The importance of intermediary servers is their ability to provide load-balancing cache sharing.

What Is CRUD?

CRUD is an acronym that stands for CREATE, READ, UPDATE, and DELETE. These four database commands are the foundation of CRUD. This acronym is well-known among programmers, but many software developers view it as more of guidance since CRUD was not made as a modern way to create API. After all, its origins are in the database. By its definition, it’s more of a cycle than an architectural system.

Many programming protocols and languages have their CRUD version with different names and a slight change in what they do. A good example is SQL (structured query language) that uses Insert, Select, Update and Delete. Also, there are CRUD cycles in a dynamic website, such as a buyer on any eCommerce site (Amazon, Mango, etc.). The user can create an account, update information and delete things from their shopping cart. Other programming languages that use the CRUD frameworks are Java (JOOQ, iBAtis), Phyton (Django), PHP (Propel, Doctrine), and .NET (NHibernate, LLBLGEN Pro), to name a few.

A Short History of CRUD

It is thought the CRUD acronym was created in the 1980s to describe database functionality used by structured query language (SQL). The term first became known in the 1983 Book Managing the Data-base Environment by James Martin. The first reference to CRUD operations was in a 1990 article “From Semantic to Object-Oriented Data Modeling” by Haim Kilov.

The CRUD cycle was designed as a set of functions to enhance persistent storage with a database which often outlives the processes that started it. In modern software programming and development, CRUD has exceeded its start as a function and lent itself to design principles to applications like SQL, DDS, and HTTP protocol.

CREATE, READ, UPDATE, DELETE: Principles of CRUD

As discussed above, the four main principles of the CRUD cycle are: CREATE, READ, UPDATE and DELETE.

The CREATE function adds one or more entries and is the equivalent of the Insert function in SQL.
The READ function retrieves data based on different criteria and is equivalent to the Select function in SQL.
UPDATE procedures change and modify records without overwriting.
The DELETE function removes one or more entries that are specified.

L and S: Additions to CRUD

Sometimes CRUD is expanded to include LISTING (CRUDL). Listing helps with more extensive data not being stored in easy memory storage without going to pagination.

Some programmers add an S to CRUD (SCRUD) for SEARCH. With data retrieval, it is only used for updates and deletions while users of software applications sometimes need to search data in a database to see a list of search results.

What Are the Similarities Between REST and CRUD?

Some purists may argue that REST and CRUD are in no way related to one another. However, a closer look into the commands they use reveals the similarities between the two.

REST Commands

POST– This creates a new record in the database.
GET– This request reads information sourced from a database.
PUT/PATCH– This updates an object.
DELETE– This removes a record from the database.

CRUD Commands

CREATE– This creates a new record through INSERT statements. In REST, this is a POST command.
READ/RETRIEVE– These procedures grab data based on input parameters. In REST, this is equivalent to a GET command.
UPDATE– This updates data without overwriting it. In REST, this is a PUT request.
DELETE- This removes data from the database. REST uses the same request to delete data.

What Are the Differences Between REST and CRUD?

Because of the similarities between REST and CRUD, it’s easy to mistake them for having the same function. But that’s far from the truth. Delving a little bit deeper explores the differences between them.

REST is an architectural system centered around resources and Hypermedia using HTTP commands. CRUD is a cycle meant to maintain records in a database setting. In its base form, CRUD is a way of manipulating information, describing the function of an application. REST is controlling data through HTTP commands. It is a way of creating, modifying, and deleting information for the user.
CRUD functions can exist in a REST API, but REST APIs are not limited to CRUD functions. CRUD can operate within a REST architecture, but REST APIs can exist independent of CRUD. For example, a REST API can allow clients to reboot a server even if it doesn’t correspond to any CRUD functions. REST can do this as long as it uses the proper HTTP methods.
REST usually refers to using data through HTTP commands. It’s a dogma to facilitate how users manipulate data onscreen and the information that’s being saved on the server. Programmers can create a REST API that can handle the essential CRUD functions, but the same can’t be said the other way around.
The functions of REST and CRUD are similar (as discussed above), but they are not the same. PUT replaces a resource, even one that doesn’t exist yet. POST adds a new resource. Both of these commands create a new resource, but PUT is usually used to update resources that are already there. PATCH is mainly used to update a part of a resource, but PUT is used only to update an entire resource by replacing it.

REST and CRUD Work Together, but They Are Not the Same

REST and CRUD work together because CRUD can exist within a REST environment, and their functions often correspond to each other, but they are not the same. The best way to differentiate between them is to remember that REST is a standard (an API architecture), and CRUD is a function. Understanding this essential but straightforward difference is necessary for understanding both.

REST vs CRUD

Contents

What Is REST?

Brief History of REST