I’d like to clarify some things about the use of HTTP verbs for RESTful APIs and the apparent misconceptions these can bring about.
Firstly, there are a few people who believe that RESTful APIs are predominantly for CRUD (Create, Read, Update, Delete) operations. I covered how this can be extended to other operations in a previous article; Nouns and Verbs – in the world of APIs.
Secondly, there’s also a large contingency of people who believe the use of HTTP verbs, and their alignment to CRUD operations, implies that RESTful APIs are simply a representation of an underlying database table – or JDBC over HTTP as I like to call it.
In a green-field situation, it’s quite possible to create your database structure based on your API contract, but eventually, these will move apart. It’s far more expensive to change a database structure than an API contract and you cannot really version a database table change and still maintain a previous version (unless you create a new table and inherit all the complexity in your code that that creates). In any other situation, where your database is already defined, exposing your database tables as APIs is exposing your data complexity directly to your consumers – APIs should abstract complexity.
So, if the HTTP verbs of a RESTful imply CRUD operations, but these may not directly correlate with database tables; what does CRUD mean in this context? Quite simple, it means CRUD operations at the API interface level – you still need to implement the validation, transformation and mapping to wherever the data is being processed; be that your underlying database or another API.
Photo from Pexels.com