CRUD vs REST

CRUD and REST, two more prominent concepts in the app development universe, are often confused due to their overlapping nature. While 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. This blog discusses the difference and similarities between REST and CRUD and the basic principles that govern them.

What is CRUD?

CRUD acronym comes from the programming world. It refers to the four functions that were considered necessary to implement a persistent storage application: create, read, update and delete. Today however, a more prevalent term is CRUD app which acts as a user interface to view, search, create, update, and delete information over a web app or mobile app. 

Short History of CRUD

Created in the 1980s to describe database functionality used in SQL, the term first became known in the 1983 book Managing the Data-base Environment by James Martin. First reference was made in a 1990 article “From Semantic to Object-Oriented Data Modeling” by Haim Kilov. 

It was designed as a set of functions to enhance persistent storage with a database which outlives the processes that started it. In modern software development, it has lent itself to design principles to applications like SQL, DDS, and HTTP protocol. 

Principles of CRUD

CRUD is a cyclical concept. From creation of records to deletion. Let’s take a look at the four basic principles: 

1. CREATE adds one or more entries. It generates new records through an ‘INSERT’ statement.
2. READ retrieves data based on different parameters and is equivalent to the Select function in SQL.
3. UPDATE procedure is used to change and modify records without overwriting them. 
4. DELETE procedure removes one or more entries that are specified.

Other variations of CRUD include:

1. CRUDL (create, read, update, delete, listing)
2. BREAD (browse, read, edit, add, delete)
3. DAVE (delete, add, view, edit)
4. CRAP (create, replicate, append, process)

What Is REST?

The founder of REST protocol, Roy Fielding, describes REST as an abstraction of the architectural elements within a distributed hypermedia system. REST or Representational State Transfer  architectural style provides standards for systems on the web. REST dictates how the systems interact.

Short History of REST

Back in 2000 developers did not have a standard to develop a web API and used a bunch of different protocols. These protocols proved too tedious and complicated to carry out. Together with his colleagues, Roy Fielding sought to address this problem and developed the REST protocol that went on to allow 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, REST has been used in companies of all sizes, across industries.

Principles of REST

There are six guiding constraints of REST:

1. Interface/uniform contract
2. Client-server mandata
3. Statelessness
4. Cache
5. Layered system
6. Code-on-demand (optional)

Interface/uniform contract

The Uniform contract followed by RESTful architecture prohibits the use of multiple, self-contained interfaces within an API. By simplifying and decoupling  the architecture, each part gets to evolve independently. The four guiding principles of the uniform interface are: 

1. Resource-Based: Individual resources are identified in requests using URIs as resource identifiers. 
2. Manipulation of Resources Through Representations: When a client holds a representation of a resource, including any metadata attached. If it has the permission, it can modify or delete the resource on the server.
3. Self-descriptive Messages: Individual messages include sufficient information to describe how to process the message. 
4. Hypermedia as the Engine of Application State: Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. 

Client-server

This mandate enforces the separation of concerns, which helps the client and the server components evolve independently. Separating the user interface concerns (client) from the data storage concerns (server) improves the portability of the UI across multiple platforms and improves scalability by simplifying the server components.

While the client and the server evolve, it is important that the contract between the client and the server does not break.

Statelessness

Statelessness is a guiding principle of RESTful architecture owing to its nature. It mandates that each request from the client to the server must contain all of the information necessary to understand and complete the request.

To implement stateless requests, the communication between consumer and service is initiated by the request, and the request contains all the information necessary for the server to respond. Server cannot take advantage of previously stored context information. So, the client application must entirely keep the session state

Cacheable

Cache mandate requires that the server responses be labeled as either cacheable or not. Caching helps to mitigate some of the constraints of statelessness. Say a request gets cached by the consumer in an attempt to avoid re-submitting the same request twice.

Layered system

This principle is responsible for making RESTful architecture scalable. In a Layered System, multiple layers are used to grow and expand the interface. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.

CRUD vs Rest

CRUD vs REST similarities

CRUD can be mapped to DDS, SQL and HTTP protocols. The HTTP protocols are a link between resources in RESTful architecture which is a core piece of REST’s foundation.

The REST architecture is used to execute CRUD operations in web applications. Each letter, or operation, that CRUD represents can be mapped to an HTTP protocol. Take a look: 

Matching the CRUD acronym with HTTP

CRUD OPERATIONS <-> HTTP PROTOCOL

Create        Post

Read        Get

Update        Put

Delete        Delete

The confusion around REST and CRUD has to do with the overlapping of basic commands.  While the similarities cannot be dismissed, it should be noted that REST is not simply the same as CRUD. RESTful architecture means more than mapping GET, PUT, POST commands.

CRUD vs REST – Differences 

There are some things one must consider when comparing CRUD and REST. While the former is a cycle meant for maintaining permanent records in a database setting, REST is an architectural system centred around resources and hypermedia, via HTTP protocols.

CRUD is mapped to REST to comply with the goals of RESTful architecture. In REST, the representations must be uniform with regard to resources.

CRUD vs REST

DronaHQ offers a faster way to move data from data sources  into your front end tool to be visualized.  DronaHQ is a low code platform hence it comes with over 100+ prebuilt components that can be dragged and dropped into a screen to design web or mobile based interfaces to interact with a data source. DronaHQ provides a pre-built REST API connector that will allow you to integrate data from a plethora of custom and non-native sources, popular databases like MySQL, PostgreSQL, MongoDB, MS SQL or by configuring REST or GraphQL APIs in just a few clicks. You could build a CRUD app using DronaHQ platform, connecting to your data source or database via a REST API.

Want to take DronaHQ for a spin? Explore the platform for free and experience the feature-rich low code tool first hand.