easyMultiple Choice
200-901 Practice Question: A developer is designing a REST API that will be…
A developer is designing a REST API that will be used by multiple client applications. The API must support versioning to ensure backward compatibility. Which approach should the developer use to implement API versioning?
⚠ Common exam trap
Cisco often tests the misconception that query parameters or custom headers are more 'RESTful' or flexible, but the exam expects URI-based versioning as the simplest and most compatible approach for backward compatibility.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Embed the version in the URI, e.g., /v1/resource
Embedding the version in the URI (e.g., /v1/resource) is the most common and straightforward approach for REST API versioning. It makes the version explicit in the URL, allowing clients to directly target a specific version without requiring special header handling or query parameter parsing. This method is widely adopted in industry APIs (e.g., GitHub, Twilio) and ensures backward compatibility by keeping older endpoints accessible under their original URI path.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Embed the version in the URI, e.g., /v1/resource
Why this is correct
Placing the version in the URI path creates a distinct endpoint per version, so clients calling /v1/resource remain unaffected when /v2 is introduced. This satisfies the backward-compatibility constraint by letting old and new contracts coexist without breaking existing consumers.
- ✗
Use different HTTP methods for different versions
Why it's wrong here
HTTP methods denote operations on resources, not API versions, so reusing them for versioning breaks REST semantics and caching. It is tempting because methods already vary requests, but versioning belongs in the URI path or a dedicated header.
- ✗
Pass the version as a query parameter, e.g., ?version=1
Why it's wrong here
Query parameters are optional and easily omitted, so clients may silently receive the default version, undermining backward compatibility. It is tempting because it avoids URI restructuring, and it would suit non-breaking, optional feature toggles rather than enforced API versions.
- ✗
Use a custom HTTP header to specify the version
Why it's wrong here
A custom HTTP header carries version metadata but is invisible to intermediaries and requires bespoke client handling, so it does not satisfy the stem's requirement. It is tempting because headers avoid changing the URI, and it would suit internal APIs where clients are controlled.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.