InternshipAll 60 tasks, level by level
The real graded API Design tasks the portal assigns, grouped into three levels.
The portal assigns these API Design tasks. Finish Level 1 before Level 2 and Level 2 before Level 3. Your mentor may mark some tasks as required for the certificate.
Level 1: Foundations (24 tasks)
| Task | What to do |
|---|---|
| What an API is | Explain APIs, clients and servers, and compare REST, GraphQL, gRPC and webhooks in a table. |
| HTTP for API designers | Document every HTTP method and the 15 most useful status codes with when to return each. |
| Resource naming | Design URLs for a hospital system (patients, doctors, appointments) using nouns, plurals and nesting rules. |
| Request and response design | Write example JSON requests and responses for each endpoint with consistent field naming. |
| Error format | Design one error response format (RFC 9457 problem details or your own) and use it for 6 error cases. |
| Study a great API | Review the public docs of a well-designed API (Stripe, GitHub or Twilio) and list 10 design choices you like. |
| OpenAPI first | Write an OpenAPI 3 file for the hospital API before any code, in a repo named api-design-internship. |
| Mock server | Run a mock server from your OpenAPI file (Prism or Postman mock) and call it. |
| Query parameters | Design filtering, sorting, field selection and search parameters for the appointments list. |
| Pagination | Compare offset, page-number and cursor pagination and design cursor pagination for one endpoint. |
| Idempotency | Explain idempotent methods and design an Idempotency-Key header for creating payments. |
| API style guide | Write a one-page API style guide for your team covering naming, dates, errors and versioning. |
| Design review checklist | Write a 25-point API design review checklist. |
| Naming exercise | Rename 15 badly named endpoints and fields and explain each change. |
| Status code decisions | For 15 scenarios, choose the right status code and justify it. |
| Enums and nulls | Decide how your API represents enums, missing values and empty lists, and document it. |
| Money and units | Design how prices, currencies and units are represented (for example paise as integers). |
| Localisation in APIs | Design how your API handles language and time zones. |
| Bulk operations | Design a bulk create endpoint with partial failure reporting. |
| Search API | Design a search endpoint with filters, facets and sorting. |
| File upload API | Design direct-to-storage file upload with pre-signed URLs. |
| API changelog | Write a changelog for three versions of your API. |
| Postman collection | Publish a Postman collection with examples for every endpoint. |
| Linting OpenAPI | Lint your OpenAPI file with Spectral and fix the warnings. |
Level 2: Building real features (20 tasks)
| Task | What to do |
|---|---|
| Implement the API | Implement the hospital API from your OpenAPI file and check the code matches the contract. |
| Contract tests | Add tests that fail when the implementation stops matching the OpenAPI contract. |
| Authentication design | Compare API keys, OAuth 2.0 and JWT, and design authentication for patients, doctors and partner apps. |
| Authorisation | Design scopes or roles so each client can only reach the data it should, and test them. |
| Versioning | Compare URL, header and media-type versioning and make a breaking change safely with a new version. |
| Rate limiting design | Design rate limits per client and the response headers that tell clients their limit. |
| Caching headers | Use ETag, Cache-Control and conditional requests on read endpoints and show a 304 response. |
| Long-running operations | Design an endpoint that starts a report job and lets clients poll or receive a webhook when it is done. |
| Webhooks design | Design webhooks with event types, retries, signatures and a test endpoint. |
| Developer docs | Publish interactive docs with examples, a quickstart and an authentication guide. |
| SDK generation | Generate a client SDK from your OpenAPI file and use it in a small app. |
| Consumer-driven contracts | Use Pact or a similar tool for consumer-driven contract tests. |
| Hypermedia links | Add useful links (next page, related resources) to responses. |
| Partial responses | Support a fields parameter so clients can request only the fields they need. |
| Concurrency control | Use ETags with If-Match to prevent lost updates. |
| Batch requests | Design a batch endpoint for several operations in one call and explain the trade-offs. |
| Event-driven API | Describe an event stream with AsyncAPI. |
| Public vs internal APIs | Write the different rules you would apply to public and internal APIs. |
| Developer onboarding | Design the sign-up to first API call journey with API keys and a sandbox. |
| Error catalogue | Publish a catalogue of all error codes with causes and fixes. |
Level 3: Professional work and capstone (16 tasks)
| Task | What to do |
|---|---|
| GraphQL schema | Design a GraphQL schema for the same domain and compare it with your REST design. |
gRPC service | Define a gRPC service in a .proto file for internal service-to-service calls and generate a client. |
| API gateway | Put a gateway in front of your API for auth, rate limits and logging. |
| API security review | Review your API against the OWASP API Security Top 10 and fix at least three issues. |
| Deprecation plan | Write a deprecation policy and announce the retirement of an old endpoint with Sunset headers. |
| API analytics | Log usage per endpoint and client and build a small dashboard of calls, errors and latency. |
| Design review | Review a classmate's API design with a checklist and suggest concrete improvements. |
| Capstone: public API product | Ship a documented, versioned, secured API with an SDK or client example, tests, a changelog and a design document explaining your choices. |
| API product thinking | Write a one-page API product plan: users, value, pricing tiers and limits. |
| Gateway policies | Configure quotas, caching and auth policies in an API gateway. |
| Multi-version support | Run two API versions side by side from one codebase and test both. |
| Breaking change rollout | Plan and simulate a breaking change rollout with communication and metrics. |
| Security testing | Run automated API security tests (ZAP API scan or similar) and fix findings. |
| API governance | Write governance rules for a company with 10 teams building APIs. |
| Design critique | Critique a public API's design and propose improvements with examples. |
| Capstone 2: API platform | Deliver an API platform with gateway, docs portal, SDK, sandbox, analytics and a deprecation policy. |