5 exercises — essential API design terms: REST vs GraphQL, idempotency, rate limiting, and versioning strategies. Practised daily by backend and full-stack developers.
API management: versioning · breaking change · backward compatibility · deprecation · API key · OAuth · JWT
0 / 10 completed
1 / 10
Which statement best describes a REST API?
REST (Representational State Transfer) is an architectural style defined by Roy Fielding. Key constraints: stateless (each request contains all the info the server needs — no session stored server-side), resource-based (URLs identify resources: /users/42, not /getUser?id=42), uniform interface (standard HTTP verbs — GET reads, POST creates, PUT/PATCH updates, DELETE removes). A RESTful API follows these constraints. Common vocabulary in API discussions: endpoint (a specific URL + method), resource (the noun — user, order, product), representation (the JSON/XML sent over the wire), HATEOAS (Hypermedia as the Engine of Application State — responses include links to related actions). Contrasted with: GraphQL (option C) and gRPC (option A).
2 / 10
A developer says: "Our mobile app was suffering from over-fetching — every product list call returned the full product object including description, specs, and reviews, but the list view only needed name, price, and thumbnail." Which API technology is the developer most likely about to switch to?
GraphQL (developed at Facebook, open-sourced 2015) solves over-fetching and under-fetching. A GraphQL client sends a query specifying exactly the fields it needs: { product { name price thumbnail } } — only those fields are returned. Over-fetching: REST returns too many fields (wasted bandwidth — especially painful on mobile). Under-fetching: REST requires multiple requests to get all needed data (N+1 problem — also solved by GraphQL's nested queries). Key vocabulary: schema (type definitions — the contract), query (read operation), mutation (write operation), subscription (real-time updates via WebSocket), resolver (function that fetches data for a field), introspection (clients can query the schema itself). Trade-off: GraphQL is more complex to cache (every request is POST to a single endpoint).
3 / 10
In API design, what does idempotency mean, and which HTTP method is defined as NOT idempotent?
Idempotency: calling an operation once produces the same outcome as calling it N times. This matters for fault-tolerant clients: if the network fails after the server processes a request but before the client receives the response, the client can safely retry an idempotent operation. HTTP method idempotency: GET ✅ (read, no state change), PUT ✅ (replace resource — calling twice gives the same state), DELETE ✅ (deleting a deleted resource is still "deleted"), POST ❌ (not idempotent — submitting an order form twice creates two orders). Safe methods (no side effects): GET, HEAD. Idempotent but not safe: PUT, DELETE. Neither safe nor idempotent: POST. Practical tip: use idempotency keys (a unique client-generated ID sent with the request) to make POST endpoints idempotent — Stripe does this for payment requests.
4 / 10
Complete with the correct API term: "Our public API allows 1,000 requests per hour per API key. If a client exceeds that limit, we return HTTP 429 with a Retry-After header. This is called _____ limiting."
Rate limiting controls how many requests a client can make in a given time window to protect the API from abuse, ensure fair usage, and prevent resource exhaustion. HTTP 429 = "Too Many Requests." Common strategies: fixed window (1,000 req/hour resets at :00), sliding window (any 60-minute window — smoother), token bucket (replenishes tokens at a fixed rate — allows controlled bursts), leaky bucket (processes requests at a fixed rate — smooths spikes). Response headers: X-RateLimit-Limit (total limit), X-RateLimit-Remaining (remaining in current window), X-RateLimit-Reset (when window resets, Unix timestamp), Retry-After (seconds to wait). Rate limiting per client can be keyed by: API key, IP address, user ID, OAuth scope. Related: throttling (slowing requests down rather than blocking them), quota (longer-term total limit — e.g., 1M req/month).
5 / 10
A senior developer reviews a PR and comments: "We should add API versioning before going public. I'd recommend the URL path approach." Which format is the URL path approach?
API versioning lets you evolve an API without breaking existing clients. The four common strategies: (1) URL path (/v2/users) — most common, explicit, easily testable in a browser, visible in logs; (2) Query parameter (?version=2) — less clean, works but pollutes query strings; (3) Header versioning (Accept: application/vnd.myapi.v2+json or X-API-Version: 2) — clean URLs but harder to test, invisible in browser. URL path versioning is preferred for public APIs (it's explicit and discoverable). When to version: when you make a breaking change (removing fields, renaming fields, changing data types, removing endpoints). Non-breaking additions (new optional fields, new endpoints) generally don't need a version bump. Key vocabulary: breaking change, backward compatibility, deprecation notice, sunset header (HTTP header indicating when an old version will stop working).
6 / 10
Sarah from the frontend team is frustrated with the current API. She says, 'Every time I request user details, I get a huge response containing all their past orders, addresses, and even old passwords – it's taking forever to load!'. Which design principle is Sarah most likely criticizing?
Sarah's complaint highlights over-fetching, where the API returns more data than the client actually needs. This leads to increased bandwidth usage, slower response times, and a poor user experience. Rate limiting is a defense against abuse but doesn't directly address the problem of receiving excessive data. Data masking protects sensitive information, and caching strategies mitigate response times, but don't address the initial excessive data retrieval.
7 / 10
Mark leaves this code review comment on a PR: 'This endpoint returns all product details regardless of whether the user is viewing them or just searching. We should consider pagination to improve performance.' What specific API design concept does Mark suggest implementing?
Mark is referring to pagination. Pagination involves dividing a large dataset into smaller pages that are returned in response to user requests. This significantly reduces the amount of data transferred and improves performance, especially for lists or tables. GraphQL schema definition relates to query structure, API documentation generation is about describing the API, and request throttling is a mechanism to limit rate.
8 / 10
David sends this message in a Slack channel: 'I'm getting a 400 Bad Request error when I send the API request. The documentation says I need to provide a valid user ID, but it's not working.' What is the *most likely* reason for David's issue?
David's error suggests an invalid input. A 400 Bad Request typically indicates that the server received a request that it couldn't understand due to incorrect data format, missing required parameters (like the user ID), or other malformed content. While timeout issues, network problems, and expired keys can cause errors, they usually result in different HTTP status codes.
9 / 10
Elena writes the following description for a PR introducing a new API endpoint: 'This endpoint allows clients to retrieve product details based on a unique SKU. It returns only the name, price, and image URL – minimizing bandwidth usage. Versioning is handled through the URL path (e.g., `/api/v1/products/{sku}`).'. What API design pattern does Elena's PR primarily demonstrate?
Elena's description clearly shows a resource-based RESTful API. This pattern focuses on exposing resources through URLs and returning only the necessary data for each resource. The URL path approach to versioning is a common technique in REST APIs. SOA, microservices, and event-driven architectures represent different architectural styles that aren't directly reflected in this PR's design.
10 / 10
Ben is giving a standup update: 'I'm working on improving the API's error handling. I've implemented consistent JSON responses for all errors and added detailed error codes to help developers debug issues faster.' Which aspect of API design does Ben's work primarily focus on?
Ben's efforts are centered around API discoverability and usability. Providing consistent JSON responses with detailed error codes allows developers to quickly understand the nature of errors and troubleshoot them more effectively. Rate limiting deals with resource control, data modeling is about structuring data, and security protocols relate to authentication/authorization.
What does the "API Design Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to api design vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 2 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.