Master the IT-English vocabulary of versioning APIs between microservices: backward compatibility, breaking changes, deprecation and contract evolution.
0 / 15 completed
1 / 15
A change is described as 'backward compatible'. What does that mean?
A backward-compatible change doesn't break existing clients; they continue to work unmodified.
2 / 15
Removing a required field from a response is a 'breaking change'. Why?
Removing or renaming fields breaks consumers that depend on them, requiring coordinated updates.
3 / 15
A team 'deprecates' the v1 endpoint. What does deprecation signal?
Deprecation marks an API as obsolete and slated for removal, prompting consumers to move off it.
4 / 15
Adding a new optional field is usually safe because?
Additive, optional changes are typically non-breaking since tolerant readers ignore unknown fields.
5 / 15
Which sentence correctly uses 'contract'?
The API contract is the agreed interface; honouring it lets services evolve without breaking each other.
6 / 15
Alice from the Infrastructure team just commented on a PR: 'We're moving to API version 2.0 for the user profile service. Version 1 is now fully deprecated.' What does 'deprecated' typically signify in this context?
'Deprecated' doesn't imply automatic changes or immediate deletion. Instead, it signals that the older version is no longer actively maintained and should be migrated away from. It often means continued support for existing integrations *will* exist for a limited time – allowing developers to update their code gradually. The key takeaway is a recommendation against using the older version.
7 / 15
Ben (Lead Developer) sends this Slack message: 'Just noticed the API response for user authentication is returning a 401 Unauthorized error. It seems like the v3 endpoint requires a new authorization header – 'X-API-Key' – which wasn't present in the older versions.' What is Ben highlighting?
Ben's message points to an incompatibility. The API response's error (401) indicates the client wasn't providing the correct data. A change in required headers—like 'X-API-Key'—demonstrates that the newer version has different contract requirements, necessitating code updates to accommodate the new authentication method.
8 / 15
Sarah from the Frontend team is writing a PR to update our application's API calls. She mentions that we're planning to transition to API version 3.0 for the product catalog service. Which of the following best describes the *purpose* of communicating this change proactively?
Communicating a planned API version transition proactively is crucial for minimizing disruption and allowing developers sufficient time to adapt their code. 'Backward compatible' versions are maintained for a period, but eventually, older endpoints become unsupported. This approach allows for a smoother upgrade process and reduces the risk of unexpected issues. The goal isn't immediate enforcement, but rather a controlled migration.
9 / 15
David, a junior developer, is reviewing a PR that introduces a new field – 'user_metadata' – to the `/users` API endpoint. He asks for clarification on whether this represents a 'breaking change'. What does David likely mean?
A 'breaking change' in an API signifies that modifying it introduces incompatibilities with older versions. Adding a new, required field fundamentally alters the structure of the response and can cause existing clients to fail if they don't handle the new data correctly. It's important to clearly communicate these changes so developers can update their code accordingly.
10 / 15
John from the Backend team sent this code review comment: 'This change introduces a new field, `user_id`, to the `/users` API endpoint. It's backward compatible with v1, but we should consider if it's a breaking change for clients expecting only the old fields.' What does backward compatible mean in this scenario?
Backward compatible APIs allow existing clients (code) to continue working without modification. This is achieved by adding new functionality or fields while maintaining compatibility with previous versions. The key is that the core API behavior remains consistent; only *optional* features are introduced. Option A describes forward compatibility, not backward.
11 / 15
Maria from the API team sent this message in a Slack channel: 'We're planning to introduce a new version of the payment service, v2.0, which will require clients to use a different request format. Version 1 is still supported for now.' What does Maria primarily communicate about the future state of the payment service?
Maria indicates a *coexistence* strategy. 'Supported' here means the older version (v1) will continue functioning while a newer one (v2.0) is introduced. The key concept is often 'backwards compatibility' – allowing existing clients to use the new version without requiring immediate modification. Option A is incorrect as it suggests complete replacement; option C is partially correct but doesn't capture the nuance of ongoing support.
12 / 15
During a standup meeting, you're discussing changes to the reporting API. You explain that adding a new field – 'report_date' – to the `/reports` endpoint is *not* considered a breaking change because it only affects clients who specifically request reports with date information. Which of the following best describes this approach?
This scenario focuses on *optional* features. Adding a new field that only impacts a subset of users (those requesting date-based reports) is a common and safe practice in API versioning. A 'breaking change' implies the addition fundamentally alters how existing clients use the API – something not indicated here. Options A and B are incorrect, as they relate to mandatory fields or core functionality changes.
13 / 15
David, a junior developer, is reviewing a PR that introduces a new endpoint: `/products/{product_id}/reviews`. The documentation states this is version 2.0 of the product reviews API. A senior developer comments: 'We're deprecating v1 of this endpoint – it will eventually be removed.' What does 'deprecate' most likely mean in this situation?
'Deprecate' signifies a transition phase. It doesn't mean immediate deletion; instead, it signals that the older version (v1) should be phased out in favor of the newer one (v2.0). Clients are encouraged to migrate, but the old endpoint is kept around for a limited time to allow for a smooth transition – a common strategy to avoid disrupting existing integrations.
14 / 15
During code review, you see this comment on a PR: 'To ensure long-term stability of the user authentication service, we're introducing versioning. Version 3.0 will require all requests to include an API key.' What is the primary reason for implementing API versioning in this case?
API versioning is fundamentally about managing *change*. Introducing an API key requirement (a backward-incompatible change) allows the team to cater to different client needs – perhaps newer clients require enhanced security. The goal isn't performance or architectural simplification; it's adaptability and controlled evolution.
15 / 15
You are investigating an issue where a client application is receiving a 403 Forbidden error when attempting to access the `/orders` endpoint. The API documentation states that version 2.0 requires authentication via JWT (JSON Web Token). Which of the following best describes the core problem and its resolution?
This scenario directly addresses a *versioning* issue. The 403 error indicates an authorization problem – the client isn't sending the correct authentication method (JWT) required by version 2.0. Option A describes key management; option B is the core of the problem; option C refers to server-side configuration, and option D addresses network connectivity.
What will I practise in "API Versioning Across Services"?
This module focuses on Microservices Language — real workplace phrasing you'll use on the job. It contains 15 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 15 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Microservices Language exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around microservices language — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Microservices Language exercises?
See the Microservices Language hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.