Build server-driven navigation

Problem

What becomes confusing, fragile, or impossible without understanding build server-driven navigation? This lesson answers that through explanation, a worked example, two runnable exercises, and a reference solution. No teacher-supplied worksheet is required.

HTTP and hypertext scale by exchanging representations through standardized methods, status codes, headers, links, and forms.

Concept explanation

Build server-driven navigation belongs to “Hypermedia controls state”. build server-driven navigation ships as one thin, inspectable slice of a server-rendered hypermedia workflow.

For build server-driven navigation, trace concrete input, state transition, output, and failure through a request/response contract whose method, status, headers, representation, and next actions are observable.

A client sends a request; a server returns a representation plus metadata. Hypermedia controls advertise valid next actions. Apply that model to supplied normal, boundary, and failure cases; each case below names its input and expected evidence.

Example bank

Compare normal, boundary, failure, and cross-layer cases. Predict each observation before revealing the explanation.

Worked example

Start from supplied lab.sh. Focus: Add build server-driven navigation to a server-rendered hypermedia workflow; demo it with: Build three server-rendered states connected only by links and POST forms.

1. Run: chmod +x lab.sh && ./lab.sh
2. Save baseline evidence. Compare curl -v output, request method, status, cache metadata, redirects, and representation bytes.
3. Boundary case: Document and test shipped slice under: Disable JavaScript and complete full workflow.
4. Failure case: Add recovery behavior and a regression check for: Submit invalid transition and return useful 4xx representation with recovery link.

RESULT
Fresh clone or blank directory can run documented slice and reproduce: Every state exposes next valid actions; refresh after POST does not duplicate mutation; failure remains navigable. Starter-level baseline: headers.txt begins with an HTTP status line; body.txt contains the representation; byte count is greater than zero.

Starter material

Create lab.sh, paste this exact content, then run the command below.

#!/usr/bin/env sh
set -eu
url="${1:-https://example.com/}"
printf '%s\n' '# build server-driven navigation'
curl -sS -D headers.txt -o body.txt "$url"
sed -n '1,12p' headers.txt
printf 'body bytes: ' && wc -c < body.txt

STOP / CLEANUPNo background process. Remove headers.txt and body.txt only after saving evidence.

Independent exercise

Make it recoverable: build server-driven navigation

1. Create second case from blank file: Document and test shipped slice under: Disable JavaScript and complete full workflow.
2. Then create controlled failure: Add recovery behavior and a regression check for: Submit invalid transition and return useful 4xx representation with recovery link.
3. Use curl · Chromium Network · server logs to prove behavior, then repair controlled failure.
4. Compare result against supplied acceptance checks and reference approach before marking complete.

Expected result

• Fresh clone or blank directory can run documented slice and reproduce: Every state exposes next valid actions; refresh after POST does not duplicate mutation; failure remains navigable.
• headers.txt begins with an HTTP status line; body.txt contains the representation; byte count is greater than zero.
• Controlled build server-driven navigation failure produces captured evidence; repair restores stated invariant without hiding error.

Hints

Solution

Attempt both exercises before opening reference approach.