Production engineering
Reveal answer and reasoning
Design version evolution around the behavior promised to existing and new consumers. Name required and optional members, request constraints, statuses and failure representations, then decide which changes require another supported contract. Preserve old-route tests during a transition rather than assuming the new implementation automatically keeps them. The portable parser illustrates one breaking rename and one tolerated addition, while real HTTP verifies the sample routes.
A production migration adds deprecation policy, ownership and consumer evidence; none follows solely from an explicit v2 path or a successful serializer operation.
For a rollout, inventory actual consumer dependencies before selecting a version-selection mechanism. Test old clients against the intended compatible surface and new clients against the new contract, including failures and omitted optional data. Keep deprecation communication and support duration explicit instead of hiding them in route naming. A generated schema can help compare shapes, but it cannot know every behavior a client relies on.
Require independently specified contract checks so implementation and test do not simply copy the same mistaken assumptions about a renamed member or an error category.
What a strong answer covers
- The known name predicate prints accepted,accepted,rejected.
- All actual example routes return200, so status alone cannot prove representation compatibility.
- Compatibility is relative to supported consumer behavior, not guaranteed by an optional-looking field or v2 label.
Common pitfall
Using a versioned URL, successful status or server build as proof that existing clients remain compatible.
Follow-up questions
- Which strict consumer would reject an added field?
- How could an unchanged successful body still hide a breaking error or request contract?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.