Practice the key verb+noun collocations used when publishing, deprecating, versioning, and migrating APIs in English.
0 / 5 completed
1 / 5
Fill in: 'We plan to ___ the new Payments API to external partners next quarter.'
We 'publish an API' — 'publish' is the standard collocation for making an API formally available with documentation. 'Release' is used for software versions; 'expose' is a technical term (exposing endpoints), not a business-level collocation; 'open' needs an adverb ('open up').
2 / 5
Fill in: 'We will ___ the /v1/users endpoint in six months; consumers should migrate to /v2.'
We 'deprecate an endpoint' — 'deprecate' is the precise technical term for marking an endpoint as obsolete while keeping it available during a migration window. 'Retire' is the eventual step after deprecation; 'remove' is the final action; 'disable' implies stopping it immediately.
3 / 5
Fill in: 'Adding a required field to the request body will ___ backward compatibility for existing consumers.'
We 'break backward compatibility' — 'break' is the fixed collocation for introducing a change that causes existing clients to fail. 'Lose' implies it disappears passively; 'damage' is informal; 'affect' is too vague.
4 / 5
Fill in: 'We follow semantic versioning to ___ our API so consumers know the scope of each change.'
We 'version an API' — 'version' used as a verb is the standard collocation for applying a versioning scheme. 'Number' implies sequential integers only; 'label' is used for containers or releases; 'tag' is specific to git, not API versioning.
5 / 5
Fill in: 'After the new API is stable, we will ___ all remaining consumers from v1 to v2.'
We 'migrate consumers' — 'migrate' is the technical collocation for moving clients from one API version to another. 'Move' is generic; 'transfer' implies relocating data or ownership; 'upgrade' is used for software versions, not API consumers.