Diagnose a local HTTP API from request and response evidence, distinguish transport from application failures and write a reproducible bug report.
A local-only fixture exposes GET /health and GET /items. Requests to an unknown path return 404; an unsupported method on a known path returns 405. The exercise binds to loopback and contains no authentication or real user data.
| Request | Expected status | Meaning |
|---|---|---|
| GET /health | 200 | healthy fixture |
| GET /items | 200 | two sample items |
| GET /missing | 404 | unknown route |
| POST /items | 405 | unsupported method |
A connection problem and an HTTP error occur at different layers. If a server returns a status, a connection and response have already happened. Record method, URL, headers, status and body before guessing a cause. The networking lesson supplies layer context; official HTTP documentation fills the protocol details.
Classify connection refused, 404 and malformed JSON by failure layer.
Diagnostic map
Record your result and evidence here or in a separate file.
An HTTP error is not mislabeled as DNS failure.
Start from the evidence actually received.
Bind the example to 127.0.0.1 and use a chosen local port. Avoid publishing it to the internet for this exercise. Keep endpoints small and deterministic. A health response says this fixture handled a request; it does not certify a database or dependent service that the fixture does not have.
Start the server and request /health and /items.
Local request log
Record your result and evidence here or in a separate file.
Both expected 200 responses have the documented JSON shape.
Check content type and body as well as status.
Negative cases reveal routing and method behavior. A 405 response should identify supported methods for the resource. A 404 should not accidentally return an unrelated success page. Keep error bodies consistent enough for clients to understand while avoiding unnecessary internal details.
Request an unknown route and POST to /items.
Failure-case evidence
Record your result and evidence here or in a separate file.
Statuses are 404 and 405; the latter advertises GET.
Compare the exact path and method before editing code.
Change one fixture expectation in a test copy and use the request log to identify the mismatch. A good repair addresses the contract rather than merely changing the test until it passes. Preserve the original expected behavior and explain why the implementation or specification should change.
Introduce a wrong item count in a test, diagnose it and restore the contract.
Bug report and repair note
Record your result and evidence here or in a separate file.
The report includes a copyable local request and observed response.
Avoid screenshots without the request details needed to reproduce the issue.
A runbook should proceed from connectivity to status, headers and payload. Include how to stop the local server and rerun checks. Do not include secrets in logs. This fixture intentionally omits authentication, persistence and production hardening so the protocol evidence stays easy to inspect.
Write a five-step diagnostic runbook and retain the test output.
HTTP debugging pack
Record your result and evidence here or in a separate file.
A reviewer can reproduce the four cases on loopback.
State the local-only scope next to the start command.
Deliver the fixture, four request checks, one bug report and the diagnostic runbook. Demonstrate that a failed connection is reported differently from a returned 404.
Tests remain local and response status is not treated as proof of every payload or dependency.
| Criterion | Points | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
The four case statuses are 200, 200, 404 and 405. A 404 is an application-level route response, while a refused connection produces no HTTP status from this server. The /items body contains exactly two synthetic items.
This is HTTP diagnosis for a local fixture, not a deployed API or authorization test against a third-party system.