What is the client-server contract?
The contract is the agreement between front and back about how they talk: the URLs, methods, request shapes, response shapes, and status codes. Both sides must honor it. As a full-stack developer you write both halves, so you define and keep this contract yourself.
Why it matters
Most full-stack bugs are contract mismatches — the client sends a field the server does not expect, or reads a response shape the server no longer returns. Owning both sides is an advantage only if you keep the contract consistent. It is the foundation the entire seam stage builds on.
What to learn
- HTTP methods and status codes from both sides
- JSON request and response bodies
- Headers, content types, and CORS
- Designing a consistent request/response shape
- Error response shapes
- Versioning the contract as it changes
- Keeping client and server in agreement
Common pitfall
Changing a response shape on the server and forgetting the client still expects the old one — a silent break that only shows at runtime. Because you own both sides, it is tempting to change one in a hurry. Change the contract deliberately, update both halves together, and (in the seam stage) let shared types enforce it.
Resources
Primary (free):
- MDN — HTTP overview · docs
- MDN — JSON · docs
- MDN — CORS · docs
Practice
Define a small contract for one endpoint: the method, URL, request body shape, success response shape, and error shape. Build both the client call and the server handler to honor it exactly, including a CORS setup if they are on different origins. Done when client and server agree on every field.
Outcomes
- Define a consistent request/response contract.
- Use methods, status codes, and JSON correctly on both sides.
- Handle CORS between client and server.
- Change the contract without silently breaking a half.