REST API Testing Workbench

Testing a REST API is a daily engineering task — fire a request, read the status code, inspect the JSON, iterate — but students usually meet it only as theory. Lab machines often lack installed API clients, and public test APIs are rate-limited or change without notice, so the request/response loop never becomes muscle memory. ReqForge closes that gap with a self-contained workbench: the request builder, a deterministic mock e-commerce API (products and orders), response inspection with syntax highlighting, a saved collection and a replayable history, all in one page. Every HTTP concept in the syllabus — methods, status codes, headers, JSON bodies, auth tokens, validation errors — is demonstrated live and repeatably, with zero setup and zero network dependency.

1. The builder assembles the request: method, URL, custom headers, raw JSON body, and the bearer token attached as an Authorization header.
2. On Send, a short simulated latency plays, then the mock router parses the URL path and method.
3. The router matches method + path against its route table — collection routes vs item routes, products vs orders — and extracts path parameters and query strings.
4. Route handlers run realistic logic: filtering and limiting lists, looking up items by ID, validating required fields on create (422 if missing), merging partial updates, and returning deleted records.
5. The response renderer displays the status code with its reason phrase, elapsed milliseconds, payload size and request ID, then the syntax-highlighted JSON body.
6. The exchange is appended to history; clicking any history entry reloads that request and its saved response.

Tech stack:

• HTML5, CSS3 (dark workbench theme)
• Vanilla JavaScript (no frameworks)
• In-browser mock API router (method + path matching)
• Tokenizer-based JSON syntax highlighter
• No backend, no dependencies — runs offline

• [Request builder] HTTP method selector, URL bar, and tabbed panels for headers, JSON body and bearer-token auth, with a Send button and loading state.
• [In-browser mock API] A simulated e-commerce API (products + orders) with full CRUD, realistic data, and correct status codes: 200, 201, 400, 404 and 422 for validation failures.
• [Response inspector] Pretty-printed JSON with syntax highlighting, status line with reason phrase, elapsed time, payload size and a generated request ID per call.
• [Saved collection] Seven prebuilt requests covering list, get-one, create, update, delete and order flows — click any entry to load and fire it.
• [Request history] Every exchange is logged and clickable, so any previous request can be replayed and its response re-inspected.
• [API reference view] In-page documentation of every mock endpoint, its parameters and its error codes, generated from the same route table as the mock.
• [Query and validation behavior] Working ?limit and ?category filters, required-field validation (422), malformed-JSON handling (400) and unknown-route errors (404).

• Complete single-file web app (workbench + mock API + docs views)
• Documented mock router code (route matching and handler logic explained)
• Project report PDF (background, REST/HTTP theory, methodology, screenshots)
• PPT presentation for final review
• Viva Q&A preparation document (methods, status codes, headers, JSON, auth)
• User guide for running and demonstrating the workbench

• The API is simulated in the browser — it does not make real network requests and cannot test external APIs.
• No persistence beyond the session: created/updated records reset on page reload.
• Authentication is illustrative (a static mock token), not a real OAuth/JWT flow.
• The mock covers one e-commerce domain; it is not a generic HTTP client for arbitrary URLs.
• Simulated latency is fixed, not measured network timing.