Api Design medium
Which of the following is a BREAKING change to a REST API?
- A Adding a new optional field to a response body that older clients are configured to ignore during deserialization.
- B Removing or renaming a field in the response body that existing clients rely on for their internal logic or UI display.
- C Introducing a new optional query parameter that defaults to a backward-compatible value if omitted by the client.
- D Adding a completely new endpoint to the API surface area that does not affect the behavior of existing URI paths.
Answer: B. Removing or renaming a field in the response body that existing clients rely on for their internal logic or UI display.
In REST API evolution, removing a field that clients rely on is a **breaking change** because existing clients will fail to parse or process the response as expected. Adding optional fields or new endpoints is generally backward-compatible (non-breaking) because clients effectively ignore unknown fields.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You're designing a REST API for a blog. Which endpoint best represents 'get all comments for post 123'?
- A client wants to update only the 'status' field of an order, leaving other fields unchanged. Which HTTP method is most appropriate?
- A client calls POST /users with valid data, and the user is created. What status code should the server return?
- A client retries a failed 'POST /payments' request due to network timeout. The server receives the request twice. Without idempotency handling, what can happen?
- An API returns 10,000 products. Returning all in one response is impractical. Which pagination approach is simple and stateless?
- Your API serves both mobile apps and third-party integrations. Which authentication method is most appropriate?