Member-only story
Is Task-Based API a Better Solution Than CRUD APIs?
A technique from the past that should be abandoned

CRUD is simple. CRUD is life. This is what many web developers prayerfully have inside their heads. This pattern is too damn important to be ignored. Every application needs some simple endpoints, don't they?
Create, Read, Update, and Delete — So simple and so wrong.
The problems emerge right after designing your application’s endpoints in this simple manner.
Tell Me! What’s Not Good About It?
Okay, sure! Let's face it with a simple model that represents a RedditUser
.
You obviously need to design some API to interact with that model. Seriously, you need to store and update this user somewhere.
All of a sudden, you remember that posts are likable and increase Karma
. How on earth do you implement this feature?
Quickly done with CRUD, you remember. U stands for "update." Your API is designed to have it like so: PATCH api/reddituser/{id}
taking the entire user.
Wait, what? Update only Karma
and deliver the entire RedditUser
object?
What's your problem? Just deliver the god damn user.
Seeing it so is rough since someone has to deal with it, and this might be you. There's no chance for you to see which properties will be updated by calling this endpoint.
Code should always express itself to the best. This is also valid for API. Hence the used CRUD approach becomes verbose.