Junior · Explain · Versioned routes and consumer compatibility

Why can an extra response member be compatible for one consumer while renaming name to displayName breaks it despite200?

Think through your answer before opening the explanation.

Production engineering

Reveal answer and reasoning

An API version declares an intended client contract, not merely a different route spelling. A successful status can carry a breaking representation, while adding a field can be harmless to a consumer that deliberately ignores unknown members. The fixture exposes explicit v1 and v2 routes without a versioning library making compatibility decisions on the application's behalf. The portable program uses a real JSON parser to check a narrow required-name rule.

It does not start HTTP, infer OpenAPI or establish that every existing client is tolerant of added fields and unchanged error behavior.

Renaming a required field is not made compatible by returning200 or adding v2 to a URL. Conversely, an optional response field is not universally harmless: some clients use strict schemas or derive behavior from an enum or set of recognized members. Compatibility needs a named consumer contract and supported versions. This companion checks only one property over known objects, so malformed syntax or a changed id type would require additional checks.

Do not use a green server build or a generated document as a substitute for independently executing the clients and failure categories that the rollout promises to support. A consumer might also depend on status meanings, enum values or omission rules even when property names remain unchanged, so those contracts deserve independent examples.

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

  1. Which strict consumer would reject an added field?
  2. 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.

Primary references

Open lesson and code ↗

← All interview questions