Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Clients often deploy at different speeds. A stable boundary lets the server and its consumers evolve independently without exposing storage models or turning every internal refactor into a coordinated release.
I use explicit request and response DTOs whose fields have documented meaning, nullability, formats, and ownership. Requests expose only values the caller may set, while responses expose the stable state clients need. I prefer additive optional response fields and avoid renaming, removing, or changing the meaning of existing fields. Domain entities and database rows stay behind the boundary so an internal refactor does not silently change JSON.