3. Web, Network and API Architecture

Introduction and Context

A scalable web application is not merely a collection of screens and database tables. It is a distributed system whose components communicate across networks, often through several layers of addressing, transport, security, routing, caching, and service mediation. When a user enters a web address, the browser must discover the server, establish a network connection, negotiate security, send an HTTP request, receive a response, interpret application data, and often perform many additional requests for scripts, stylesheets, images, and API resources. Each stage introduces architectural choices and possible failure modes.

For a full-stack developer, understanding these layers is essential. A slow application may be suffering from inefficient database queries, but it may also be affected by DNS delays, connection establishment, TLS negotiation, poor cache policy, an overloaded reverse proxy, an inappropriate load-balancing algorithm, or an API that transfers excessive data. Similarly, reliability and security cannot be added only at the application-code level; they must be designed across the network and protocol stack.

This chapter examines the interaction between browsers, networks, servers, intermediaries, and APIs. It explains DNS, TCP/IP, TLS, HTTP, proxies, load balancers, gateways, and content delivery networks. It then develops design principles for REST, GraphQL, gRPC, and real-time APIs, including versioning, pagination, idempotency, rate limiting, observability, and lifecycle governance.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain how DNS, TCP/IP, TLS, and HTTP cooperate during a web request.

2. Distinguish among forward proxies, reverse proxies, load balancers, API gateways, and CDNs.

3. Analyse browser-server interaction and identify likely sources of latency or failure.

4. Compare REST, GraphQL, gRPC, and real-time communication models.

5. Design APIs using appropriate resource models, status codes, pagination, versioning, idempotency, and rate limits.

6. Evaluate security, reliability, observability, governance, and operational trade-offs in API architecture.

7. Apply these concepts to the design of a scalable web platform.

From a Browser Address to an Application Response

Consider a user requesting `https://shop.example.com/products/42`. The visible URL conceals a sequence of operations. The browser first determines whether it already knows the destination through its own cache, the operating system cache, or a configured DNS resolver. If necessary, DNS translates the domain name into an IP address. The browser then opens a transport connection to the destination, normally using TCP for HTTP/1.1 or HTTP/2, or QUIC over UDP for HTTP/3.

For HTTPS, the client and server perform a TLS handshake. They negotiate cryptographic parameters, authenticate the server using a certificate, and establish session keys. The browser then sends an HTTP request containing a method, target path, headers, and possibly a body. The request may pass through a CDN, firewall, reverse proxy, load balancer, and API gateway before reaching an application service.

The server returns an HTTP response with a status code, headers, and representation. A successful HTML response may cause the browser to request additional JavaScript, CSS, fonts, and images. JavaScript may subsequently call JSON APIs, open a WebSocket connection, or use server-sent events. Thus, the performance of a page is determined not only by server computation but also by the number, size, ordering, and locality of network exchanges.

DNS: Naming Rather Than Location

The Domain Name System is a distributed hierarchical naming system. It separates a human-oriented name from the changing network location of a service. A typical lookup may involve a browser cache, operating-system resolver, recursive resolver, root name server, top-level-domain server, and authoritative name server.

Common DNS records include:

• A: maps a name to an IPv4 address.
• AAAA: maps a name to an IPv6 address.
• CNAME: aliases one name to another name.
• MX: identifies mail exchange servers.
• TXT: stores text used for verification and policy mechanisms.
• NS: identifies authoritative name servers.
• SRV: describes service locations, where supported by the application.

DNS responses have a time-to-live (TTL), which controls how long resolvers may cache them. A short TTL permits faster changes but creates more resolver traffic; a long TTL improves cache efficiency but makes migration and failure recovery slower. DNS-based traffic distribution can support geographic or weighted routing, but it is not a substitute for an application-aware load balancer because cached responses cannot be changed instantly and client location is only approximated.

DNS is also a security boundary. DNSSEC can provide authenticity for DNS responses, while operational controls should protect domain registration, authoritative servers, and credentials. A DNS failure can make a healthy application appear unavailable, so domain monitoring and controlled change procedures are essential.

TCP/IP and the Transport of Data

The Internet protocol suite is commonly discussed through layers. IP provides addressing and packet routing. TCP provides an ordered, reliable byte stream with retransmission, flow control, and congestion control. UDP provides a connectionless datagram service with lower protocol overhead but no built-in delivery guarantee or ordering. HTTP/3 uses QUIC, which runs over UDP while implementing reliable streams, encryption integration, and improved handling of connection migration.

TCP begins with a three-way handshake. Connection establishment adds latency, especially when the client and server are geographically distant. Persistent connections reduce this cost by allowing multiple HTTP exchanges over one connection. HTTP/2 multiplexes multiple streams over a connection and compresses headers, while HTTP/3 reduces some head-of-line blocking effects by using independently managed QUIC streams.

Network reliability does not imply application reliability. TCP may successfully deliver a request to a server that later fails during processing. A client timeout can occur even though the server eventually completes the operation. This distinction explains why distributed applications require timeouts, retries, idempotency, and careful failure handling.

TLS and the Meaning of HTTPS

Transport Layer Security protects data in transit through confidentiality, integrity, and server authentication. During a TLS handshake, the client and server negotiate a protocol version and cipher suite, authenticate the server certificate through a trusted certificate authority, and derive symmetric session keys. Symmetric encryption is then used for efficient data transfer.

HTTPS protects the connection between two TLS endpoints. If TLS terminates at a CDN or reverse proxy, the internal connection from that intermediary to the application must also be protected where confidentiality or identity assurance is required. This arrangement is often called TLS termination or TLS offloading. It simplifies certificate management for internal services but creates a responsibility to secure the proxy-to-service segment.

Certificates must be renewed, monitored, and correctly associated with hostnames. Secure deployments should disable obsolete protocols, use secure cookie attributes, avoid mixed content, and apply appropriate security headers. TLS does not validate that an authenticated user is authorised to access a particular resource; authentication and authorisation remain application concerns.

HTTP as an Application Protocol

HTTP is a request-response protocol. Its methods carry semantic expectations:

• GET retrieves a representation and should be safe and idempotent.
• POST commonly creates a subordinate resource or requests an operation; it is not inherently idempotent.
• PUT replaces a resource representation and is generally intended to be idempotent.
• PATCH partially modifies a resource, with idempotency depending on the operation design.
• DELETE removes a resource and is generally treated as idempotent, although the first request may change state.

HTTP status codes communicate broad outcomes. The 2xx family indicates success, 3xx redirection, 4xx client-side problems, and 5xx server-side failures. Useful API responses include `201 Created` with a `Location` header, `202 Accepted` for asynchronous processing, `204 No Content` for successful operations without a response body, `400 Bad Request` for malformed input, `401 Unauthorized` when authentication is absent or invalid, `403 Forbidden` when access is denied, `404 Not Found`, `409 Conflict`, `429 Too Many Requests`, and `500` or `503` for server or temporary availability problems.

Headers convey metadata and control behaviour. `Content-Type` describes the representation format; `Accept` expresses acceptable response formats; `Cache-Control` defines caching rules; `ETag` identifies a representation version; `If-None-Match` enables conditional retrieval; and `Retry-After` can indicate when a client should retry. Cookies support stateful browser interactions, but they should use `Secure`, `HttpOnly`, and appropriate `SameSite` attributes.

The Intermediary Architecture

Modern web traffic rarely travels directly from a browser to an application process. Intermediaries improve performance, security, scalability, and manageability, but each additional layer must be observable and correctly configured.

A forward proxy acts on behalf of clients. It may enforce corporate policy, filter destinations, or cache outbound content. A reverse proxy acts on behalf of servers. It can terminate TLS, route requests, compress responses, apply security rules, and conceal internal topology.

A load balancer distributes traffic among healthy service instances. Layer 4 balancing uses transport information such as IP addresses and ports. Layer 7 balancing understands HTTP attributes such as hostname, path, headers, and cookies. Algorithms include round robin, weighted distribution, least connections, and latency-aware routing. Health checks must test meaningful service readiness rather than merely whether a process accepts a port connection. Session affinity can simplify stateful applications, but it reduces flexibility and can create uneven load; shared or external session storage is often preferable.

An API gateway is an application-aware entry point for APIs. In addition to routing, it may authenticate requests, enforce quotas, transform protocols, aggregate calls, validate schemas, and provide central observability. Excessive gateway responsibilities can create a bottleneck or an organisational dependency, so policies should be centralised when consistency is valuable and kept within services when domain-specific.

A content delivery network (CDN) places cacheable content near users. Static assets, images, video segments, and carefully designed API responses can be served from edge locations. CDN effectiveness depends on cache keys, freshness rules, invalidation strategy, and content privacy. Personalised responses should not be cached publicly unless the cache key and access controls are rigorously designed. Cache poisoning and accidental exposure of private responses are serious risks.

Designing Service APIs

An API is a contract between independently evolving consumers and providers. A technically functional endpoint may still be a poor contract if its naming, error model, consistency, or evolution policy is unclear.

REST and Resource-Oriented Design

REST-style APIs use resources, representations, standard HTTP semantics, and stateless interactions. A design might expose `/customers/18/orders` rather than an action-heavy endpoint such as `/getCustomerOrders`. Resource orientation does not prohibit actions; operations that do not map naturally to CRUD may use explicit subordinate action resources, such as `/payments/123/capture`.

Good REST design uses stable identifiers, consistent representations, predictable status codes, content negotiation where justified, and meaningful validation errors. A response should not force clients to infer success from a message string. Error bodies should provide a machine-readable code, human-readable explanation, and, where useful, field-level details and a correlation identifier.

Pagination is necessary when collections can grow. Offset pagination is simple and supports navigation to an approximate page, but inserts and deletions can cause duplicates or omissions. Cursor pagination uses a position derived from a stable ordering, such as `(created_at, id)`, and is generally more reliable for changing large datasets. A cursor should be opaque to clients and treated as an expiring continuation token rather than a database offset.

Filtering, sorting, and field selection must be constrained. Arbitrary query expressions can create security and performance problems. Limits should have safe defaults and maximum values. Bulk operations need explicit semantics, especially concerning partial success and retry behaviour.

GraphQL

GraphQL presents a typed schema through which clients select the fields they need. It can reduce over-fetching and under-fetching, particularly for rich user interfaces that combine related data. A single query may retrieve a graph of related objects, while mutations represent state changes and subscriptions support event-oriented updates.

GraphQL introduces different operational concerns. A query can be syntactically valid but computationally expensive through deep nesting, aliases, or large lists. Production systems therefore use depth or complexity limits, query cost analysis, persisted queries, field-level authorisation, and resolver instrumentation. The N+1 problem occurs when resolving a list causes one backend request per item; batching and caching techniques such as a data loader pattern can reduce this cost.

GraphQL errors may coexist with partial data, so clients must inspect both the data and errors fields. Schema evolution usually favours additive changes and deprecation rather than frequent URL versions. This supports flexible clients but requires strong schema governance.

gRPC and Internal Service Communication

gRPC uses Protocol Buffers for compact, strongly typed messages and commonly runs over HTTP/2. It supports unary, server-streaming, client-streaming, and bidirectional-streaming calls. Generated client and server code improves consistency across languages and makes contracts explicit.

gRPC is often effective for internal service-to-service communication where controlled clients, low latency, streaming, and strong typing matter. It is less convenient for direct browser use, although gRPC-Web and translation gateways can help. Operational design must include deadlines, cancellation, retry policies, status codes, backward-compatible schema evolution, and message-size limits. A retry policy must distinguish transient failures from permanent application errors.

Real-Time APIs

Polling repeatedly asks whether new information exists. Long polling keeps a request open until data is available or a timeout occurs. Server-sent events provide a one-way, persistent HTTP stream from server to browser. WebSockets provide a long-lived, bidirectional channel suitable for chat, collaborative editing, live dashboards, and interactive sessions.

Real-time systems require heartbeat or ping mechanisms, reconnect logic, event identifiers, ordering decisions, and a policy for missed events. A client that reconnects must know whether it can resume from a sequence number or must obtain a fresh snapshot. Horizontal scaling often requires a shared broker or event distribution layer because a connection may terminate on one instance while an event is produced by another.

API Evolution and Operational Governance

Versioning and Compatibility

An API contract evolves under pressure from new features, security requirements, and data-model changes. URL versioning, such as `/v2/orders`, is visible and operationally simple. Header or media-type versioning keeps URLs stable but can be less discoverable. Schema evolution without major versions is possible when changes are backward compatible.

Backward-compatible changes generally include adding optional response fields or introducing new endpoints. Risky changes include renaming fields, changing data types, removing values from an enumeration, altering error meanings, or making an optional request field mandatory. Providers should publish a deprecation policy, communicate timelines, measure client usage, and offer migration documentation. Versioning is not only a technical mechanism; it is a governance decision about who bears the cost of change.

Idempotency and Safe Retries

Retries are useful when failures are temporary, but they can duplicate side effects. A client retrying a payment or order creation request may produce two outcomes unless the server can recognise that both requests represent one intended operation.

An idempotency key is a client-generated unique token associated with an operation. The server stores the key and result for an appropriate period and returns the original result when the same key is received again. The key must be bound to the authenticated client and request parameters; reusing it with different parameters should produce an error. Idempotency does not mean every request is harmless. It means repeated equivalent requests converge on one effect.

Retries should use bounded exponential backoff with jitter, respect `Retry-After`, and avoid retrying validation failures or non-transient authorisation failures. Timeouts must be explicit at every relevant layer. A timeout at an intermediary should not exceed the ability of downstream services to complete safely.

Rate Limiting and Capacity Protection

Rate limiting protects fairness, cost, and availability. A fixed-window counter is easy to implement but can allow bursts at window boundaries. A sliding window provides a more accurate view of recent traffic. Token-bucket algorithms permit controlled bursts while enforcing an average rate. Limits may be applied per IP address, account, API key, tenant, route, or a combination.

A useful limit response communicates that the request was rejected because of capacity policy, commonly through status `429` and relevant limit or retry information. Rate limits should be designed with legitimate usage patterns in mind. They should not be the only defence against abuse; authentication, input validation, anomaly detection, and network-level controls may also be needed.

Observability and Reliability

API observability combines logs, metrics, and traces. Logs should include structured fields such as request ID, trace ID, route, status, latency, authenticated principal, and error category, while avoiding secrets and unnecessary personal data. Metrics should distinguish request rate, error rate, latency distributions, saturation, cache hit ratio, and dependency failures. Distributed tracing follows a request across gateways and services.

Service-level indicators should reflect user experience, such as successful request rate and latency at high percentiles. Alerts should be tied to meaningful service-level objectives rather than every transient error. Circuit breakers, bulkheads, bounded queues, graceful degradation, and load shedding can prevent one failing dependency from exhausting the entire system.

Security, Governance, and Professional Responsibility

API security begins with threat modelling. Common threats include broken object-level authorisation, injection, credential theft, excessive data exposure, replay, abuse of expensive queries, and insecure defaults. Authentication establishes identity; authorisation determines permitted action on a particular resource. These must be tested separately.

Sensitive data should be minimised, encrypted in transit and at rest where appropriate, and retained only as long as justified. Logs should not expose passwords, access tokens, payment data, or unnecessary personal information. CORS should allow only required origins, methods, and headers. CSRF protections are important for cookie-authenticated browser applications. API keys and tokens need rotation, secure storage, scope limitation, and revocation procedures.

Governance includes API ownership, documentation, schema review, contract testing, changelogs, dependency management, incident response, and a retirement process. OpenAPI can document HTTP APIs; Protocol Buffer definitions document gRPC contracts; GraphQL schemas are executable contracts. Documentation must describe authentication, errors, limits, examples, pagination, consistency expectations, and deprecation status.

Illustrative Case Study: Scaling a Multi-Region Learning Platform

Background

Assume an online learning platform serving recorded lessons, assessments, instructor dashboards, and live classroom events. Its initial architecture uses one application server, a relational database, direct object storage downloads, and a REST API. As enrolment grows, users report slow page loads, duplicated enrolments after network failures, and intermittent failures during examination periods.

Situation and Analysis

A trace of a typical page shows repeated DNS and connection costs because clients do not reuse connections. Large videos are downloaded from the application region rather than an edge cache. The database is overloaded by unbounded course-list queries. The load balancer considers a process healthy even when the database connection pool is exhausted. Finally, the enrolment endpoint creates a record before responding, but clients retry after a timeout, producing duplicates.

Approach

Static assets and video segments are placed behind a CDN with signed URLs for protected content. A reverse proxy terminates TLS and routes API requests to multiple instances. Health checks are changed to verify application readiness, including critical dependency capacity. Course lists use cursor pagination and indexed ordering. The enrolment endpoint accepts an idempotency key and enforces a uniqueness constraint on `(student_id, course_id)`. A rate limit protects examination and enrolment routes, while ordinary catalogue browsing receives a separate quota.

The platform retains REST for public browser APIs, uses server-sent events for instructor notifications, and adopts gRPC for selected internal calls. Correlation IDs and distributed traces expose latency across the gateway, course service, and database. A deprecation policy is introduced before releasing a new API representation. Sensitive examination responses are excluded from public caching and logs.

Outcome

The architecture reduces origin bandwidth, prevents duplicate enrolments, and makes overload visible before total failure. More importantly, it aligns each mechanism with a specific problem: the CDN addresses content locality, cursor pagination addresses large changing collections, idempotency addresses uncertain retries, and readiness checks address misleading health signals.

Learning Points

Scalability is not achieved by adding servers alone. The design must account for network distance, intermediary behaviour, state, failure semantics, data sensitivity, and contract evolution. Reliable APIs treat retries and partial failure as normal operating conditions rather than exceptional events.

Current Developments and Emerging Directions

HTTP/3 and QUIC are increasingly relevant for mobile and geographically distributed users because they combine encrypted transport with stream-based communication and connection migration. Edge computing moves selected computation closer to users, but it requires careful control of state, deployment consistency, and data sovereignty. Service meshes can provide service identity, traffic policy, retries, and telemetry, although they also add operational complexity and should not replace sound application-level design.

Event-driven architectures and asynchronous APIs are expanding beyond traditional request-response interactions. Webhooks, message brokers, and event streams allow producers and consumers to evolve more independently, but they require delivery guarantees, deduplication, ordering policies, schema governance, and replay strategies. AI-assisted development can generate API documentation, tests, and client code, yet generated artefacts still require human review for security, privacy, compatibility, and domain correctness.

Best-Practice Design Guidance

A professionally managed web and API architecture should:

• define clear boundaries among DNS, edge, gateway, service, and data layers;
• use TLS throughout all sensitive network paths and manage certificates proactively;
• set explicit timeouts, bounded retries, and cancellation behaviour;
• choose REST, GraphQL, gRPC, or real-time protocols according to client, data, and operational needs;
• paginate large collections and impose safe query and payload limits;
• make side-effecting operations idempotent when clients may retry;
• separate authentication from resource-level authorisation;
• treat caching as a correctness concern as well as a performance technique;
• publish schemas, compatibility rules, deprecation schedules, and error contracts;
• instrument gateways and services with logs, metrics, and traces; and
• test failure modes, overload, security boundaries, and contract compatibility before production release.

Chapter Summary

Web architecture is a chain of cooperating layers. DNS resolves names; IP routes packets; TCP or QUIC transports data; TLS provides secure communication; HTTP expresses application requests and responses. Browsers often communicate through CDNs, reverse proxies, load balancers, and API gateways before reaching services. These intermediaries improve performance and control but introduce configuration and observability responsibilities.

REST uses resource-oriented HTTP interactions, GraphQL provides typed client-selected queries, gRPC offers strongly typed efficient service communication, and real-time protocols support persistent event delivery. Effective APIs require explicit pagination, status codes, error contracts, versioning, idempotency, rate limiting, timeouts, retries, and lifecycle governance. Security requires both transport protection and correct authentication and authorisation. Scalable architecture is therefore a coordinated design of protocols, intermediaries, contracts, operational controls, and failure behaviour.

Key Terms

DNS: A hierarchical system that maps domain names to network-related records.

TCP: A reliable, ordered transport protocol that provides a byte stream between endpoints.

QUIC: An encrypted, multiplexed transport protocol used by HTTP/3 over UDP.

TLS: A protocol providing confidentiality, integrity, and endpoint authentication for network communication.

HTTP: An application-layer request-response protocol used extensively for web communication.

Reverse proxy: An intermediary that receives requests on behalf of backend servers.

Load balancer: A component that distributes requests among service instances.

API gateway: An API-aware entry point that can route, authenticate, transform, and govern requests.

CDN: A distributed network that serves cacheable content from locations near users.

REST: An architectural style using resources, representations, stateless interactions, and HTTP semantics.

GraphQL: A typed API query language allowing clients to request selected fields and relationships.

gRPC: A strongly typed remote procedure call framework commonly using Protocol Buffers and HTTP/2.

Idempotency: The property that repeating an equivalent operation produces the same effective result.

Pagination: A method of dividing a collection into manageable response segments.

Cursor pagination: Pagination using an opaque continuation position based on stable ordering.

Rate limiting: Controlling request frequency or volume for a client, identity, route, or tenant.

TLS termination: The point at which an intermediary decrypts and processes TLS traffic.

Service-level objective: A target for a measurable reliability or performance indicator.

Contract testing: Testing whether a service implementation conforms to an agreed API contract.

Review Questions

Short Answer Questions

1. What is the purpose of DNS TTL?

2. Distinguish a forward proxy from a reverse proxy.

3. Why are readiness checks more useful than simple process checks for load balancing?

4. What problem does cursor pagination address?

5. Why does TLS not replace application-level authorisation?

Long Answer Questions

1. Trace a browser request from URL entry to application response, identifying the role of DNS, transport, TLS, HTTP, and intermediaries.

2. Compare REST, GraphQL, and gRPC in terms of contracts, client flexibility, performance, and operational concerns.

3. Explain how idempotency keys, timeouts, and retry policies work together in a reliable API.

4. Discuss the design and governance responsibilities of an API gateway.

5. Explain how a CDN, caching headers, and privacy requirements must be coordinated.

Analytical / Application Questions

1. An order API times out after creating an order, and the client retries. Design a protocol and server-side strategy that prevents duplicate orders.

2. A GraphQL endpoint is experiencing high CPU usage because clients submit deeply nested queries. Propose technical and governance controls.

3. A multi-region application has inconsistent results when users paginate through a changing collection. Analyse the likely cause and recommend a pagination and consistency strategy.

22. Multiple Choice Questions with Answers

Question 1

Which sequence best represents the major stages of a typical HTTPS browser request?

A. HTTP response, DNS lookup, TLS handshake, IP routing

B. DNS resolution, transport connection, TLS handshake, HTTP exchange

C. TLS handshake, DNS resolution, HTTP exchange, transport connection

D. IP routing, HTTP exchange, DNS resolution, certificate issuance

Correct Answer: B. DNS resolution, transport connection, TLS handshake, HTTP exchange

Question 2

Why can a long DNS TTL complicate a rapid failover?

A. It prevents TLS from encrypting the replacement server

B. It causes TCP to abandon persistent connections

C. Resolvers may continue using an outdated address

D. It disables HTTP status codes

Correct Answer: C. Resolvers may continue using an outdated address

Question 3

Which characteristic most directly distinguishes a reverse proxy?

A. It acts on behalf of clients requesting external destinations

B. It receives requests on behalf of backend servers

C. It replaces DNS with a database lookup

D. It guarantees that all requests reach the same server

Correct Answer: B. It receives requests on behalf of backend servers

Question 4

A collection changes frequently while clients retrieve it page by page. Which pagination approach generally reduces omissions and duplicates?

A. Unlimited offset pagination

B. Random page selection

C. Cursor pagination with stable ordering

D. Pagination based only on response size

Correct Answer: C. Cursor pagination with stable ordering

Question 5

A client may retry a payment request after a timeout. Which design most directly prevents duplicate processing?

A. A longer HTML cache duration

B. An idempotency key bound to the request and client

C. A DNS CNAME record

D. Disabling all HTTP status codes

Correct Answer: B. An idempotency key bound to the request and client

Question 6

Which situation is especially appropriate for GraphQL complexity controls?

A. A client submits deeply nested queries that consume excessive server resources

B. A TLS certificate is nearing expiration

C. A DNS resolver has cached an address

D. A TCP connection uses a persistent session

Correct Answer: A. A client submits deeply nested queries that consume excessive server resources

Question 7

Which protocol is commonly suited to strongly typed internal service communication with generated client code?

A. gRPC

B. FTP

C. SMTP

D. CSS

Correct Answer: A. gRPC

Question 8

What is a primary risk of publicly caching personalised API responses at a CDN?

A. The response may expose one user's data to another user

B. The response will always become larger than the request

C. The CDN will be unable to resolve any domain name

D. TCP will stop providing ordered delivery

Correct Answer: A. The response may expose one user's data to another user

Question 9

What does HTTP status 429 normally communicate?

A. The resource was permanently deleted

B. The client must authenticate using TLS

C. The request exceeded a rate or capacity limit

D. The server created a new resource

Correct Answer: C. The request exceeded a rate or capacity limit

Question 10

Which statement best describes authentication and authorisation?

A. Authentication determines identity; authorisation determines permitted access

B. Authentication caches content; authorisation resolves DNS

C. Authentication replaces TLS; authorisation replaces HTTP

D. Authentication controls pagination; authorisation compresses headers

Correct Answer: A. Authentication determines identity; authorisation determines permitted access