Backend Development APIs and Web Services Syllabus

APIs and Web Services syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for APIs and Web Services in Backend Development, not a summary of it.

1. 1

   REST API Design

   6 topics

   • REST Principles and Constraints
   • Resources, URIs and HTTP Verbs
   • Request and Response Modeling
   • Status Codes and Error Responses
   • Versioning Strategies
   • HATEOAS and Richardson Maturity Model
2. 2

   API Documentation and Contracts

   4 topics

   • OpenAPI / Swagger Specification
   • API-First Design
   • Schema and Contract Testing
   • Postman and API Clients
3. 3

   GraphQL

   5 topics

   • Schema Definition Language
   • Queries, Mutations and Subscriptions
   • Resolvers and Data Loaders
   • N+1 Problem and Batching
   • GraphQL vs REST Tradeoffs
4. 4

   RPC and Real-Time Communication

   5 topics

   • gRPC and Protocol Buffers
   • JSON-RPC
   • WebSockets
   • Server-Sent Events
   • Long Polling and Webhooks
5. 5

   Request Validation and Serialization

   4 topics

   • Input Validation and Sanitization
   • Schema Validation Libraries
   • Content Negotiation
   • Data Serialization Formats
6. 6

   API Gateways and Management

   4 topics

   • Rate Limiting and Throttling
   • API Keys and Quotas
   • Reverse Proxies and Load Balancing
   • CORS and Cross-Origin Requests

APIs and Web Services flashcards for Backend Development

20 of 51 cards from the APIs and Web Services deck — real questions with worked answers.

1. What does REST stand for, and who introduced it?

   REST stands for Representational State Transfer. It was introduced by Roy Fielding in his 2000 doctoral dissertation as an architectural style for distributed hypermedia systems.

2. List the six architectural constraints of REST.

   1) Client-Server, 2) Statelessness, 3) Cacheability, 4) Uniform Interface, 5) Layered System, and 6) Code on Demand (optional). Only Code on Demand is optional; the rest are mandatory for a system to be RESTful.

3. What does the 'statelessness' constraint of REST require?

   Each request from client to server must contain all information needed to understand and process it; the server stores no client session/context between requests. Session state is kept entirely on the client.

4. What are the four interface guiding principles of REST's 'uniform interface' constraint?

   1) Identification of resources (via URIs), 2) Manipulation of resources through representations, 3) Self-descriptive messages, and 4) Hypermedia as the engine of application state (HATEOAS).

5. In REST, what is the difference between a resource and its representation?

   A resource is an abstract concept/entity identified by a URI (e.g., a user). A representation is a concrete serialized snapshot of that resource's state in a particular format (e.g., JSON or XML) exchanged between client and server.

6. What is the semantic difference between a URI, a URL, and a URN?

   A URI (Uniform Resource Identifier) is the general identifier. A URL is a URI that also specifies how/where to locate the resource (includes scheme/host). A URN names a resource by unique name independent of location (e.g., urn:isbn:...). Every URL and URN is a URI.

7. Which HTTP methods are considered 'safe', and what does safe mean?

   Safe methods do not modify server state (read-only): GET, HEAD, OPTIONS, and TRACE. Clients can call them without expecting side effects.

8. Define idempotency for HTTP methods and classify the standard verbs.

   An idempotent method produces the same server state whether called once or many times. Idempotent: GET, HEAD, PUT, DELETE, OPTIONS, TRACE. Not idempotent: POST (and generally PATCH).

9. What is the difference between PUT and PATCH?

   PUT replaces the entire resource with the supplied representation (full update, idempotent). PATCH applies a partial modification to the resource (partial update, not guaranteed idempotent).

10. Which HTTP verb should create a resource when the server assigns the identifier, and why not PUT?

    POST, because the client does not know the resource's URI in advance and POST is non-idempotent (each call creates a new resource). PUT is used when the client specifies the target URI/ID and wants create-or-replace semantics.

11. What content-negotiation headers let a client and server agree on a representation format?

    The client sends Accept (and Accept-Language, Accept-Encoding) to state preferred media types; the server responds with Content-Type describing the returned representation's media type.

12. What are the five classes of HTTP status codes and their meaning?

    1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, 5xx Server Error.

13. Distinguish HTTP 401 from 403.

    401 Unauthorized means authentication is missing or invalid (the client is not authenticated). 403 Forbidden means the client is authenticated but lacks permission to access the resource.

14. When should an API return 200 vs 201 vs 204?

    200 OK: successful request with a response body. 201 Created: a new resource was created (typically with a Location header). 204 No Content: success with no response body (e.g., a DELETE or empty PUT).

15. What does HTTP 422 Unprocessable Entity signify versus 400 Bad Request?

    400 Bad Request: the request is malformed/syntactically invalid. 422 Unprocessable Entity: the syntax is valid but the request is semantically wrong (e.g., validation failure on well-formed JSON).

16. What status code indicates rate limiting, and which header commonly accompanies it?

    429 Too Many Requests indicates the client has sent too many requests in a given time. It is often accompanied by a Retry-After header telling the client when to retry.

17. What is the purpose of RFC 7807 / RFC 9457 'Problem Details'?

    It standardizes a machine-readable JSON (or XML) error response format for HTTP APIs, with fields like type, title, status, detail, and instance, using the media type application/problem+json.

18. Name four common REST API versioning strategies.

    1) URI path versioning (/v1/users), 2) Query parameter versioning (?version=1), 3) Custom header versioning (Api-Version: 1), and 4) Media type / content negotiation versioning (Accept: application/vnd.example.v1+json).

19. What is a key trade-off of URI path versioning versus media-type versioning?

    URI path versioning is simple, visible, and cache/browser-friendly but violates the idea that a URI identifies one resource. Media-type versioning keeps URIs stable and is more RESTful/HATEOAS-friendly but is less discoverable and harder to test in a browser.

20. What does HATEOAS stand for and what does it provide?

    HATEOAS = Hypermedia As The Engine Of Application State. Responses include hypermedia links so the client discovers available actions/transitions dynamically at runtime rather than hard-coding URIs.

See more APIs and Web Services flashcards →

Planning APIs and Web Services for Backend Development

APIs and Web Services (Backend Development) FAQ