Understanding and Using APIs practice questions

Client credentials

Client credentials is a defined OAuth 2.0 grant type for machine-to-machine authorisation, where the client authenticates directly and no resource owner is involved. It exchanges the client's own credentials for an access token, satisfying the question's requirement for valid grant types.

Authorization code

Authorization code is a core OAuth 2.0 grant type, exchanging a short-lived code for tokens via a back channel, which keeps credentials out of the browser. It satisfies the stem's requirement for valid grant types, alongside client credentials, implicit and resource owner password credentials.

PUT

PUT creates or fully replaces a resource at a known URI, sending the complete representation to the server. This satisfies the requirement for an HTTP method used to create or update resources in REST APIs.

POST

POST submits a payload to a collection endpoint, creating a subordinate resource, and is also used to invoke updates where the server processes the enclosed representation. That create-or-update capability is precisely what the question asks for.

5 requests per second

The Meraki Dashboard API enforces a default limit of 5 calls per second per organisation, so exceeding this threshold triggers the 429 response the developer encountered. This matches the stem's constraint precisely, confirming the rate limit that governs sustained request throughput.

pm.test("Check networks", function() { pm.expect(pm.response.json()).to.have.property('networks'); pm.response.to.have.status(200); });

The snippet satisfies both stem constraints: `pm.response.to.have.status(200)` asserts the HTTP status code, while `pm.expect(pm.response.json()).to.have.property('networks')` parses the JSON body and verifies the networks array exists. Postman's `pm.test` wrapper reports both assertions under one named test, matching the required verification of status and payload.

API key

An API key is a shared secret passed in a request header or query parameter, letting the Cisco REST API authenticate the calling application without a user session. This satisfies the requirement for a commonly used Cisco REST API authentication mechanism alongside basic authentication.

OAuth 2.0

OAuth 2.0 is a token-based authorisation framework commonly supported by Cisco REST APIs, including Webex and DNA Center. It satisfies the scenario's requirement for an authentication mechanism by issuing access tokens, letting clients call protected endpoints without embedding static credentials in every request.

Link header with rel="next"

Meraki's REST API returns an HTTP Link header containing rel="next" when further pages exist, satisfying the requirement to detect paginated responses. Following that URL retrieves the subsequent page, so the developer can iterate until no Link header appears. This is the documented cursor-style mechanism, distinct from offset or page-number parameters.

Cursor-based pagination with startingAfter parameter

Meraki's Link header supplies the next-page URL, while the startingAfter parameter carries the cursor token identifying where the subsequent page begins. Supplying that cursor to the same endpoint returns the following batch, satisfying the requirement to handle paginated responses without manually constructing offsets or tracking record counts.

Dial-in mode

Dial-in mode means the collector (client) opens the gNMI session to the target device and issues the Subscribe RPC, so subscription initiation sits with the collector. Dial-out reverses this, with the device initiating the connection. The stem specifies the collector initiates, which matches dial-in.

GET https://api.ciscospark.com/v1/teams

The Webex REST API exposes teams at /v1/teams, and retrieving a collection requires GET with no body. This satisfies the stem's requirement to list teams the authenticated user belongs to, using the bearer token for authorisation.

URLs for navigating to other pages

The Link header carries pagination metadata as URLs, using rel values such as next, prev, first and last, so clients can navigate result sets without constructing query strings manually. It satisfies the stem by supplying the URLs for other pages of the response.

API key in header

An API key placed in a request header (commonly X-Auth-Token or an Authorization variant) authenticates each REST call statelessly, requiring no session or token exchange. Cisco platforms such as Meraki and DNA Center accept this header-based key, satisfying the stem's requirement for a common Cisco REST API authentication method.

OAuth 2.0 token

OAuth 2.0 issues a bearer access token that the client presents in the Authorization header, granting scoped, time-limited access without sharing credentials. Cisco REST APIs including DNA Center and Webex support OAuth 2.0, satisfying the stem's requirement for a commonly used authentication method.

GET

GET maps to the Read operation in CRUD, returning a representation of the requested resource without modifying server state. This satisfies the stem's requirement to identify HTTP methods used for CRUD operations in REST APIs.

POST

POST maps to Create in CRUD, submitting a payload that the server uses to make a new subordinate resource. This satisfies the stem's requirement to identify HTTP methods used for CRUD operations in REST APIs.

PUT

PUT maps to the update operation in REST CRUD, replacing the target resource's full representation at its URI. It satisfies the stem's requirement for an HTTP method performing CRUD, complementing POST (create), GET (read) and DELETE (delete). Unlike PATCH, PUT sends the complete resource state, making it idempotent.

Client Credentials flow

Server-to-server without user context; suitable for non-interactive apps.

GET /dna/intent/api/v1/issues

This endpoint returns general issues, not specifically network device issues.

pm.test('Status code is 200', () => { pm.response.to.have.status(200); }); pm.test('ID exists', () => { pm.expect(pm.response.json().id).to.not.be.null; });

The `pm.response.to.have.status(200)` assertion validates the HTTP status code, while `pm.response.json().id` parses the response body and `pm.expect(...).to.not.be.null` confirms the `id` field is present and non-null. This directly satisfies both verification constraints in the stem: status 200 and a non-null `id`.

It will merge the new data into the running configuration, creating or updating as needed.

The merge operation combines supplied configuration with the target datastore, creating missing nodes and updating existing ones without deleting anything absent from the payload. Targeting running applies this directly to the active configuration, satisfying the stated edit-config behaviour.

API key in a custom header

Cisco REST APIs accept an API key supplied in a custom HTTP header, such as X-Cisco-API-Key, letting the platform identify and authorise the calling application. This satisfies the authentication requirement without embedding credentials in the URL or relying on session cookies.

OAuth 2.0 access token in Authorization header

OAuth 2.0 access tokens are a supported authentication mechanism for Cisco REST APIs, passed as a Bearer credential in the Authorization request header. This satisfies the stem's requirement for a valid authentication method, distinct from basic authentication or session cookies.

Cursor-based (e.g., startingAfter)

Cursor-based pagination returns an opaque marker such as startingAfter, which the client passes back to fetch the next page. This is distinct from offset or page-number pagination, and it satisfies the query-parameter pagination requirement reliably when records change.

Offset and limit

Offset and limit are query parameters: offset specifies how many records to skip and limit caps records returned per page. Together they satisfy the stem's requirement for valid query parameter-based pagination methods in REST APIs.

5 calls per second

The Meraki Dashboard API enforces a default rate limit of 5 calls per second per organisation, returning HTTP 429 when exceeded. This matches the stem's requested default, governing how frequently a single API key may issue requests.

Cursor-based pagination with Link header

Cursor-based pagination returns an opaque cursor marking the last item seen, and the API exposes the following page through a `Link` header carrying `rel="next"`. This satisfies the stem's requirement for header-driven navigation, unlike offset or page-number schemes that embed pagination state in query parameters or response bodies.

HEAD

HEAD retrieves only response headers, identical to GET without a body, so it causes no server-side state change and repeated calls yield the same result. This satisfies the stem's requirement for an idempotent, side-effect-free method, unlike POST or PATCH which modify resources.

GET

GET only retrieves representations and changes nothing server-side, so repeating it yields the same result — satisfying the idempotency and no-side-effects criteria the stem demands. Unlike POST, it carries no request body that could mutate state, making it inherently safe.