The Business of IT Blog

REST vs CRUD: What’s The Difference?

Stephen Watts
by Stephen Watts

Some of the confusion around REST and CRUD has to do with the overlapping of basic commands mandated by both processes. This is further amplified by the Rails community embracing REST and its GET, PUT, POST nature.

Savvy developers can see glaring similarities between GET, PUT, POST and CREATE, READ, UPDATE, DELETE. The latter commands are the foundation of CRUD. And while the similarities cannot be ignored, it should be noted that REST is not simply a carbon copy of CRUD.

REST: Foundation and Principles

Each REST command is centered around a resource. In REST, a resource is really anything that can be pointed to via HTTP protocol. For example, an image, a website, a document or a weather service. The possibilities are almost endless.

In plain terms, REST stands for Representational State Transfer, an architectural style designed for distributed hypermedia, or an Application Programming Interface. You’ve probably heard the latter referred to as an API. Another way to think of an API is to define it as a web service that conforms to the architectural principles of REST. Each API is called by issuing a standard HTTP request method: POST, GET, PUT and less commonly, DELETE. DELETE is usually implied, though not necessarily stated.

The terms that define REST principles were introduced in Dr. Roy Fieldings’ thesis, “Architectural Styles and the Design of Network-Based Software Infrastructure.” Overall, REST can be thought of as the standard in service application development. It offers an alternative to Simple Object Access Protocol (SOAP), COBRA, RMI and many others.

Principles of REST

There are six guiding constraints of REST. These are:

Client-Server Mandate

This mandate underscores the fact that REST is a distributed approach via the nature of separation between client and server. Each service has multiple capabilities and listens for requests. Requests are made by a consumer and accepted or rejected by the server.


Due to the nature of statelessness, it is a guiding principle of RESTful architecture. It mandates what kind of commands can be offered between client and server. Implementing stateless requests means the communication between consumer and service is initiated by the request, and the request contains all the information necessary for the server to respond.


Cache mandates that server responses be labeled as either cacheable or not. Caching helps to mitigate some of the constraints of statelessness. For example, a request that is cached by the consumer in an attempt to avoid re-submitting the same request twice.

Interface / Uniform Contract

RESTful architecture follows the principles that define a Uniform Contract. This prohibits the use of multiple, self-contained interfaces within an API. Instead, one interface is distributed by hypermedia connections.

Layered System

This principle is the one that makes RESTful architecture so scalable. In a Layered System, multiple layers are used to grow and expand the interface. None of the layers can see into the other.

This allows for new commands and middleware to be added without impacting the original commands and functioning between client and server.

Optional: Code-On-Demand

RESTful applications don’t have to include Code-On-Demand, but they must have Client-Server, Statelessness, Caching, Uniform Contract and Layered Systems. Code-on-Demand allows logic within clients to be separate from that within servers. This allows them to be updated independently of server logic.

REST: In a Nutshell

REST refers to a set of defining principles for developing API. It uses HTTP protocols like GET, PUT, POST to link resources to actions within a client-server relationship. In addition to the client-server mandate, it has several other defining constraints. The principles of RESTful architecture serve to create a stable and reliable application, that offers simplicity and end-user satisfaction.

CRUD: Foundation and Principles

With a better understanding of RESTful architecture, it’s time to dive into CRUD.

CRUD is an acronym for CREATE, READ, UPDATE, DELETE. These form the standard database commands that are the foundation of CRUD.

Many software developers view these commands as primitive guidance, at best. That’s because CRUD was not developed as a modern way to create API. In fact, CRUD’s origins are in database records.

By definition, CRUD is more of a cycle than an architectural system. On any dynamic website, there are likely multiple CRUD cycles that exist.

For instance, a buyer on an eCommerce site can CREATE an account, UPDATE account information and DELETE things from a shopping cart.

A Warehouse Operations Manager using the same site can CREATE shipping records, RETRIEVE them as needed and UPDATE supply lists. Retrieve is sometimes substituted for READ in the CRUD cycle.

Database Origins

The CRUD cycle is designed as a method of functions for enhancing persistent storage, for instance with a database of records. As the name suggests, persistent storage outlives the processes that created it. These functions embody all the hallmarks of a relational database application.

In modern software development, CRUD has transcended its origins as foundational functions of a database and now maps itself to design principles for dynamic applications like HTTP protocol, DDS and SQL.

Principles of CRUD

As mentioned above, the principles of the CRUD cycle are defined as CREATE, READ/RETRIEVE, UPDATE and DELETE.


CREATE procedures generate new records via INSERT statements.


READ procedures reads the data based on input parameters. Similarly, RETRIEVE procedures grab records based on input parameters.


UPDATE procedures modify records without overwriting them.


DELETE procedures delete where specified.

REST and CRUD Similarities

If you look at the two as we have described above, it may be difficult to understand why they are often treated in the same way. REST is a robust API architecture and CRUD is a cycle for keeping records current and permanent.

The lack of clarity between the two is lost for many when they fail to determine when CRUD ends and REST begins. We mentioned above that CRUD can be mapped to DDS, SQL and HTTP protocols. And that HTTP protocols are the link between resources in RESTful architecture, a core piece of REST’s foundation.

Mapping CRUD principles to REST means understanding that GET, PUT, POST and CREATE, READ, UPDATE, DELETE have striking similarities because the former grouping applies the principles of the latter.

However, it is also important to note that a RESTful piece of software architecture means more than mapping GET, PUT, POST commands.

REST and CRUD: What’s the Difference?

CRUD is a cycle that can be mapped to REST, by design. Permanence, as defined in the context of CRUD, is a smart way for applications to mitigate operational commands between clients and services.

But REST governs much more than permanence within its principles of architecture. Here are some of the ways that REST is not only different than CRUD but also offers much more.

  • REST is an architectural system centered around resources and hypermedia, via HTTP protocols
  • CRUD is a cycle meant for maintaining permanent records in a database setting
  • CRUD principles are mapped to REST commands to comply with the goals of RESTful architecture


  • Representations must be uniform with regard to resources
  • Hypermedia represents relationships between resources
  • Only one entry into an API to create one self-contained interface, then hyperlink to create relationships

The Way Forward

Developers select REST for a number of reasons.

  1. Performance
  2. Scalability
  3. Simplicity
  4. Modifiability
  5. Visibility
  6. Portability
  7. Reliability

Not surprisingly, the demand for RESTful architecture has continued to grow over the years. And, as it becomes an even more popular architectural style, developers should be able to make the distinction between the principles of other options like SOAP, COBRA and RMI.

Introducing Cognitive Service Management

Cognitive Service Management is the cutting-edge of ITSM. This innovative approach helps businesses keep up with the pace of emerging technologies and diverse environments. Download the whitepaper to learn more.
Download Whitepaper ›

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

About the author

Stephen Watts

Stephen Watts

Stephen is based in Birmingham, AL and began working at BMC Software in 2012. Stephen holds a degree in Philosophy from Auburn University and is currently enrolled in the MS in Information Systems - Enterprise Technology Management program at University of Colorado Denver.

Stephen contributes to a variety of publications including, Search Engine Journal, ITSM.Tools, IT Chronicles, DZone, and CompTIA.