Skip to content

REP.HTTP_API_TEST_MODULE.md

Latest commit

 

History

History
73 lines (62 loc) · 7.53 KB

REP.HTTP_API_TEST_MODULE.md

File metadata and controls

73 lines (62 loc) · 7.53 KB
Raw

HTTP API Test Module Implementation Report

This report tracks implementation against SPEC.HTTP_API_TEST_MODULE.md.

Status values:

  • [x] complete
  • [~] implemented with a documented limitation
  • [ ] not implemented

Breakdown

  • 1. Primary goals — single persisted collection, tree, editors, execution, response view, import/export, selectable sequential runs, and persistence are implemented.
  • 2. Postman format compatibility — the collection is retained as a JsonObject AST so unknown fields survive save/export.
  • 3. Collection tree — nested folders/requests, context operations, ordering, duplicate, move, delete confirmation, import, export, and run actions are wired.
  • 4. Node types and Postman mapping — collection, item-group folders, and request items map directly to v2.1 JSON.
  • 5. Variable system — inheritance, disabled values, recursive substitution, cycles, masking, type/enabled editing, and local/effective row views are implemented.
  • 6. URL/path variables — {{name}} and :pathVariable are resolved separately.
  • [~] 7. Collection/folder editor — Overview, Authorization, and Variables tabs are present; advanced auth value editing is intentionally compact.
  • 8. Authentication inheritance — omitted auth inherits through collection/folder/request ancestry and explicit noauth overrides it.
  • [~] 9. Authentication types — all Postman auth objects are preserved; noauth, bearer, basic, and API key execute natively, while unsupported types fail explicitly.
  • [~] 10. Credentials — sensitive values are masked by default, have an explicit reveal/edit path, and resolve only at execution; a secure vault remains future work.
  • 11. Request editor layout — method/URL/send row, configuration tabs, and response area are implemented.
  • 12. Params tab — query/path entries, duplicate ordering, enabled state, and bidirectional raw URL/query synchronization are implemented.
  • 13. Headers tab — duplicate/case/order/disabled/description fields are preserved and auth headers are generated at runtime.
  • 14. Body tab — raw, urlencoded, multipart, file, and GraphQL execution models and controls are implemented, including editable GraphQL variables and multipart text/file fields.
  • [~] 15. Authorization tab for requests — inheritance/effective source and native auth choices are shown; inherited values are read-only.
  • 16. Variables tab for requests — request-local variables and inherited effective variables are displayed separately.
  • 17. URL representation — string and structured Postman URLs are accepted and Kode-created requests use structured URLs.
  • 18. Sending requests — execution is asynchronous, cancelable, and keeps the TUI responsive.
  • 19. Request construction order — variables, URL/path/query, headers, auth, body, settings, execution, and response capture follow the specification order.
  • 20. Response panel — status, text, timing, size, body, headers, cookies, raw view, final URL, JSON formatting, and binary summaries are supported.
  • 21. Runtime response persistence — responses and cookies stay runtime-only and are not written into the collection.
  • 22. Running folders and collections — deterministic sequential execution, cancellation, selectable summary rows, captured per-request responses, and success/failure output are implemented.
  • 23. Scripts and Postman tests — events/scripts are retained losslessly and are not falsely executed.
  • 24. Settings — redirects, timeout, SSL validation, and body-mode execution settings are represented and editable; SSL validation defaults to enabled.
  • 25. Cookies — workspace runtime cookie jar, response ingestion, request reuse, expiry/path/secure handling, and a clear control are implemented.
  • 26. Import — v2.1-shaped JSON is validated, replacement is confirmed, and the original AST is retained.
  • 27. Export — only restApi.collection is exported as formatted Postman v2.1 JSON.
  • 28. Editing and persistence — edits use the workspace session, debounce behavior, and atomic .kode.json writes.
  • 29. Node creation — folders, requests, stable request IDs, and default Postman request structures are implemented.
  • 30. Rename/move semantics — rename preserves fields; move and duplicate operate on existing JSON nodes and regenerate duplicate request IDs.
  • 31. Validation and error reporting — incomplete editing is tolerated while send-time URL, variable, file, auth, and network errors remain actionable.
  • 32. Architecture — model, workspace storage, resolver, HTTP runtime, and UI layers are separate.
  • 33. Suggested execution models — immutable resolved requests and runtime-only execution results are implemented.
  • 34. HTTP client — Java HttpClient provides HTTP/HTTPS, redirects, duplicate headers, cancellation, body bytes, cookies, timeouts, and TLS defaults.
  • 35. Large responses — response previews are bounded at 10 MiB and truncation reports received/displayed sizes.
  • 36. Search/filtering — / opens a non-destructive filter over request/folder names, methods, and URLs; matching ancestors remain visible.
  • [~] 37. Keyboard usability — tree navigation, creation, rename/delete/menu, tabs, URL/body focus, send, and cancellation are available; response-pane focus navigation remains basic.
  • 38. Mouse usability — tree/context actions, tabs, send, row editing, dialogs, and response-height dragging work.
  • [~] 39. Secrets and logging — normal REST code does not log resolved credentials, sensitive UI values are masked with explicit reveal controls, and dedicated logging tests remain.
  • [~] 40. Required automated tests — model round-trip, unknown-field preservation, tree mutations, variables/auth resolution, cookies, duplicate headers, truncation, and local HTTP execution are covered; full UI and every listed HTTP matrix case remain to be expanded.
  • [~] 41. Acceptance scenario — the collection/variable/auth/request/send/reopen/export path is implemented; it still needs a manual terminal walkthrough for final UX verification.
  • 42. Explicit non-goals — cloud sync, multiple collections, environments, Vault, monitors, browser OAuth, pm.*, v3 YAML, GraphQL exploration, gRPC, WebSocket, and SOAP remain outside scope.
  • 43. Implementation approach — existing sidebar, central-pane, session persistence, event, style, and test conventions were reused.

Notes

The implementation preserves the imported Postman collection as a JSON AST. Kode-only UI state and runtime response state remain outside the exported collection document.

Verification

  • REST-focused suite: GRADLE_USER_HOME=./.gradle-user ./gradlew --no-daemon test --tests 'editor.rest.*' — 7 tests passed.
  • Kotlin compilation passed after the final UI/runtime changes.
  • A clean full-suite run completed 134 tests with one unrelated existing failure: TypescriptIdentifierPathScanTest cannot find its external TypeScript corpus fixture at TypescriptIdentifierPathScanTest.kt:20.

Implemented Components

  • editor.rest.model: lossless Postman document, paths, tree operations, workspace state.
  • editor.rest.resolve: variable inheritance/substitution, path/query construction, auth inheritance, body materialization.
  • editor.rest.http: asynchronous Java HTTP client, cookies, cancellation, bounded response capture.
  • editor.rest.ui: REST tree, context menus, import/export dialogs, collection/folder/request editor, response display.
  • src/test/kotlin/editor/rest: model, resolver, persistence-facing, and embedded HTTP regression tests.