Collaboration across the boundary.
WHAT TO AGREE EARLY
The API contract: endpoints, shapes, errors
Who owns validation rules How errors are represented Pagination and filtering conventions
WHY THE CONTRACT FIRST
Both sides can then work in parallel.
WHAT TO PROVIDE
A specification, generated and current Examples of every response, including errors A way to develop against it before it is complete
WHAT THAT LAST ONE LOOKS LIKE
A mock implementation, or a development environment.
WHAT TO BE CONSISTENT ABOUT
Response shape Error structure Naming and casing Date and time format
WHY
Inconsistency produces handling code for every special case.
WHAT TO COMMUNICATE
Any change, before it is deployed.
WHAT TO NEVER DO
Change a response shape without notice.
WHAT TO ESTABLISH ABOUT VALIDATION
That the server validates regardless, and the client validates for convenience.
WHAT TO PROVIDE IN ERRORS
Enough for the interface to show something useful, per field.
WHAT TO DISCUSS
Performance expectations, and what is realistic.
