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.

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