Backend APIs should expose business contracts rather than database tables

An order endpoint should describe an order, not force clients to understand internal storage tables.

I would define the public contract around business operations before choosing how persistence represents them internally.

Microsoft advises against APIs that mirror database structure because clients should not depend on implementation details.

Request fields, response shapes, and failure behavior deserve documentation alongside the resource names clients already use.

If integration tests expose mismatches, then boundary validation keeps the contract enforceable when external values arrive.

This separation creates room for storage changes without promising that every API evolution remains backward compatible.

Treat the API as a deliberate public agreement, then test changes against real consumer expectations.