Good API documentation relies on precise and consistent language. This quiz covers the standard collocations for documenting endpoints, writing examples, versioning specs, and reviewing changes.
0 / 5 completed
1 / 5
Fill in: 'The backend team committed to ___ all new REST endpoints before the feature is released to partners.'
We 'document endpoints' — 'document' is the standard collocation for creating formal reference material for API consumers. 'Describe endpoints' is informal and does not imply a structured format; 'explain endpoints' is too conversational; 'write endpoints' refers to coding them, not creating their documentation.
2 / 5
Fill in: 'Good API docs always ___ concrete examples showing real request and response payloads.'
We 'write examples' — in the context of documentation, 'write examples' means crafting illustrative code snippets. However, the most natural completion for 'Good API docs always ___' is 'include' in idiomatic English. 'Include examples' is the fixed collocation for documentation containing illustrative content. 'Provide' is close; 'show' and 'add' are informal.
3 / 5
Fill in: 'We use Swagger to ___ the full API reference and keep it up to date automatically.'
We 'publish a reference' — 'publish' is the collocation for making a completed API reference accessible to its audience. 'Generate' describes the automated tool process; 'create' is generic; 'host' focuses on the infrastructure rather than the act of making documentation available.
4 / 5
Fill in: 'When introducing breaking changes, always ___ the spec using semantic versioning before notifying partners.'
We 'version the spec' — 'version the spec' is the API documentation standard for applying a new version number to the OpenAPI or similar specification. 'Update the spec' is generic; 'tag the spec' refers to a git or release management action; 'increment the spec' is unusual — you increment the version number, not the spec itself.
5 / 5
Fill in: 'The developer relations team will ___ the changelog and updated examples before the next SDK release.'
We 'review changes' — 'review' is the standard collocation for a structured editorial and technical check of documentation before publication. 'Check' is informal; 'approve' is what happens after reviewing; 'edit' implies making direct changes yourself, not conducting an assessment.