Say I have a microservice that wraps a database, in a way that the entire functionality of that service is hiding the details of the database behind a generic (say REST) API, allowing changing the database without affecting the other services.
Is this an anti-pattern? What are the pros/cons of this approach?
Yes, it is an anti-pattern.
As stated in Building Micro Services 2nd page 03
If you see a microservice that just looks like a thin wrapper around database CRUD operations, that is a sign that you may have weak cohesion and tighter coupling, as logic that should be in that service to manage the data is instead spread elsewhere in your system.
It is also called the 'God-Service' anti-pattern
God Service Anti-Pattern as stated in Designing Event-Driven Systems page 81
Now creating something that looks like a kooky, shared database can lead to a set of issues of its own. The more functionality, data, and users data services have, the more tightly coupled they become and the harder (and more expensive) they are to operate and evolve.
Encapsulation aka information hiding is a well-known software design pattern. You should encapsulate your logic in one service and not expose the whole database.
