Opinionated perspective
Why Are You Still Creating CRUD APIs?
It’s an ancient paradigm better left behind.
I heard about CRUD back when I started learning programming and web development. It was pretty much the approach to use. I’d be spending time thinking about entities as ‘resources’ and how to write awesome CRUD-based applications, where each resource was either created, read, updated, or deleted, and only that. Essentially what’s best described as ‘CRUD-thinking.’
Create, read, update, delete. Simple enough — and that’s exactly the problem.
When did you last think about your domain solely in terms of storage management?
But I can see why beginners like this approach. The CRUD idea translates well into existing programming concepts, as in SQL’s INSERT, SELECT, UPDATE, DELETE
or HTTP’s GET, POST, PUT/PATCH, DELETE
.
What’s the issue with CRUD-based apps?
In my opinion, the main issue is you’re completely neglecting the user’s intention when creating a CRUD-based interface. The intention is an important aspect we, as developers, can’t sweep under the rug.
The problems arise once you start designing your application’s interface (e.g., HTTP endpoints) in a CRUD-like manner.
By the way, here’s a more in-depth article on the issues with CRUD over REST.
For instance, imagine you have an “author” model — although contrived — defined as below, and you’re developing a web API that performs some operations on the author and stores it in a database.
Then there’s an author who wants to have an additional pen name — by the way, a pen name is like an author’s ‘pseudo’ name — but the application only supports PATCH api/authors/{id}
taking the full author model as input.
At first, you might think that’s no big deal.
But, that’s a huge annoyance to the application developer. There’s no chance to guess what needs to be…