MG REST Client

A Visual Studio Code / Kiro extension for calling the Mongoose IDO Request Service REST API (V2) with a full per-operation request builder, reusable connection profiles, and a Postman-compatible test-collection workflow — assertions, value capture/chaining, response baselines, and data-driven runs that also run in Postman/Newman.

Features

Request builder

• All MG operations: GetConfigurations, GetSecurityToken, LoadCollection, UpdateCollection, InvokeIDOMethod, GetPropertyInformation, GetDocumentObjects, Download/Upload DocumentObject, Download/Upload FileStream, and Get IDO Swagger Document.
• Per-case operation & description — the Operation selector lives in the Request tab (it's a per-case property, not a global toolbar setting); the selected operation's description shows as a tooltip on the dropdown, and the resolved URL preview sits beside it (truncated, full string on hover). Each case also has a Description tab for free-text notes, saved in the collection and exported to Postman/Newman as the request description.
• Connection profiles — server, config, username, protocol, TLS-skip, and auth mode. Passwords and tokens are stored in VS Code SecretStorage, never in settings JSON.
• Runtime config picker — override the profile's config per request; click ↻ to call GetConfigurations and pick from the server's list. Used for the X-Infor-MongooseConfig header and GetSecurityToken (tokens cached per profile + config).
• Searchable IDO combobox — filters live ObjCollections as you type.
• Properties picker — modal listing the IDO's properties (GetPropertyInformation) with filter, select-all/clear, Use *, and key/read-only/required badges.
• Method & custom-load combobox — invokable methods for Invoke IDO Method; custom load methods + a Params… modal for clmparam on Load Collection.
• Update Collection editor — Edit Changes… builds the Changes body (Insert/Update/Delete, property table with Set/Null, Pick record… to capture _ItemId) with live JSON preview + Copy. For many records: collapsible change blocks with summaries, Duplicate, a Grid mode (spreadsheet: rows = records, columns = properties, per-row action) and a shared Pick record popup (with multi-select to add many Update/Delete changes at once) available in both views. On the Request tab the Changes body shows as read-only pretty-printed JSON with any {{variables}} resolved for preview (session > environment > collection; unresolved ones are left as {{…}}) — edit it with Edit Changes…, or flip the Edit raw toggle for advanced hand-editing (the raw {{…}} template is what's sent/saved).
• Parameter reference — for Invoke IDO Method, a # / Name / In-Out / Type table plus Fill template. Parameters load on demand for the selected IDO (fetched server-side and cached the first time you open that IDO's methods), so there's no slow whole-server index build; switching between methods of the same IDO is instant. An optional prebuilt index (MG: Build/Refresh Parameter Index) is still used as an offline fallback.
• Pre-send validation — required fields are checked before Send (IDO, Method for Invoke, valid JSON body); an inline warning shows and Send is disabled (with the reason) until they're fixed.
• Automatic authentication — fetches and caches the token per session; re-auths on HTTP 401.
• Self-signed certificate support — per-profile "skip TLS verification".
• IDO Editor integration — when the Mongoose IDO Editor (jeking.mg-ido-pro-editor) is installed, Open in IDO Editor ↗ is available three ways: next to the IDO field, as an editor title-bar action, and via right-click on a case in the Cases tree — each opens that IDO's metadata in the editor. Conversely, the editor's Test in REST Client command pre-fills this request form (operation / IDO / method / body). With mgRestClient.preferIdoEditorMetadata on, the builder's IDO list, methods, properties, and parameter pickers are sourced from the workspace IDO files (via the editor) instead of live REST — faster and offline, with automatic REST fallback.

Assertions, capture & variables

• Assertions / expectations — declarative checks per request (status / Success / time / body JSON path / header; equals / contains / regex / exists / numeric). Checked on Send and on runs. Saved requests embed an equivalent Postman test script, so the same checks run in Postman and Newman/CI.
• Value capture & chaining — capture response values (by JSON path) into session variables for later requests; exported as pm.collectionVariables.set(…). A 🎯 From response picker helps pick paths from the last response.
• Variables tab — edit collection variables, plus a Session variables editor to view/add/ edit/clear the runtime captured values (shared across open editors).
• Environments — named variable sets (Dev / Test / Prod) managed in the Environments view and switched from the toolbar Env picker, so the same collection runs against different targets with no edits. Import/export standard *.postman_environment.json files (Newman -e parity). An environment can also override {{config}} to retarget the database, or {{baseUrl}} to retarget the server host — applied both on Run and on an interactive Send, resolved through the full layer order (session > environment > collection > profile), so credentials stay on the active profile while the host follows the same precedence as runs.
• Per-case config + token — each case can target a different config via its Config picker (e.g. {{config_2}}) and choose its Token variable (toolbar Token field, e.g. {{token_2}}; empty = pair with the config by convention config↔token, config_2↔token_2). At run/Send time the token variable is preferred when it resolves (from a GetSecurityToken case capture or an environment) — matching Newman — and only falls back to a live per-config fetch when unresolved. The serialized request carries the chosen config/token vars, so cross-config/site integration runs behave the same in the editor and under Newman.
• GetSecurityToken credentials — token cases expose Username and Password pickers whose values are variable references only (chosen from env / collection / session vars; e.g. {{username_2}} / {{password_2}}, default {{username}} / {{password}}). No secret is ever stored in the collection. The serialized token URL is /token/{{config}}/{{username}}/{{password}} so Newman can authenticate from its environment; the extension resolves the refs (case → env → profile/SecretStorage) and passwords are masked in displayed/historied URLs.
• Variable precedence — session/captured > active environment > collection variables > per-collection overrides > active-profile defaults. The active profile's fresh token wins over a stale collection token unless pinned. Runs warn about unresolved {{placeholders}}. The same precedence applies in the editor's live Send and in collection runs (and matches Newman, where the environment overrides collection variables — keep capture names distinct from environment keys). Nested/indirect references resolve recursively — a variable whose value contains another {{var}} (e.g. item = ZTEST-{{suffix}}) is expanded to completion (bounded, with cycle protection), matching Postman/Newman.

Test Collections & the collection editor

• Test Collections view — collections as a folder/request tree. Managed (extension-created) collections support New Folder, Rename, Duplicate, Delete, and drag-drop reorder; imported collections are read-only until Enable Editing / Save Editable Copy. Edits preserve fields the extension doesn't understand. Convert-time safety check — converting a collection to editable first scans for request content MG editing can't preserve (pre-request/test scripts, per-request auth, non-raw bodies, custom headers); if any is found it stops with a list so you can cancel or knowingly convert anyway (that content is regenerated from MG metadata when a case is edited, so it would be discarded).
• Collection editor — opens a collection as one native editor with a left-hand case tree (folders + cases, collapsible), the full request builder on the right, and a draggable splitter. Per-case type dots (assertions/capture), a config tag, and a last-run/baseline badge. Run All runs every case in order; reorder via drag-drop or Move Up/Down/Move-to-Root. While a run is in progress the builder shows a busy overlay with "Running case X of N" progress and disables Send/Save/Run All (so the case can't be edited or re-run mid-run); the response column stays live so results stream in.
• Per-case config — each case can target a different Mongoose config; honored on Send and on Run All (a token is fetched per config), so one collection can span multiple configs.
• Last-run badges — pass/fail (✓/✗) and baseline (=/≠) badges on tree items, updated on Send and Run All, and persisted across reloads. A case with no assertions passes on HTTP 2xx (matching Postman/Newman, which never fail a request that has no test script); if such a response reports Success:false it's flagged with a ⚠ warning badge (passed, with a caveat) rather than failed.
• External-change aware — the tree refreshes automatically when collection files change outside the IDE (plus a manual Refresh button); the open editor reloads external edits.

Response, baseline & diff

• Side-by-side response — the request builder and the response sit in a resizable split (stacking on narrow widths), so you see the response without switching tabs. A summary strip shows the case's assertions/captures/baseline/stop/config at a glance.
• Response views — Table (MG-aware: envelope summary + a filtered table for whatever the operation returns — Load Items, Get Property Information properties/keys/sub-collections, Invoke output parameters, or any array response). A Columns picker shows/hides columns (volatile _ItemId/Bookmark hidden by default) and headers are click-to-sort (remembered per case). Long columns (e.g. _ItemId) are width-capped with hover tooltips and a copy button; nested arrays (e.g. Properties) are omitted from the parent grid. Rows that contain nested arrays (e.g. UpdateCollection Changes/Properties) can be expanded (▸) to show just those property grids (a 50/50 Name / Value grid), plus a Copy row JSON action; flat list rows (LoadCollection) stay a plain table with no extra column. Plus Body (pretty/raw), Headers, and Baseline, with Copy and an overflow menu (Save response, Set baseline, Diff vs baseline).
• Baseline regression — save a known-good response as a per-case baseline, then diff later responses against it (native side-by-side diff). The Baseline tab is read-only by default with an explicit Edit/Save/Cancel and a confirm-on-clear. Ignore fields (default _ItemId, Bookmark) exclude volatile keys from the compare/diff.

Running & CI

• Run a single request (inline ▶) or a whole collection; results go to the Test Results view and the output channel.
• Data-driven runs (experimental) — iterate a request over a CSV/JSON data file (Newman -d compatible). See below.
• Pure Postman export — Export Collection writes a clean Postman file (extension _mg metadata stripped) that runs in Postman/Newman; the editable original is untouched.
• Benchmark mode — N-iteration performance test of one request with min/median/avg/p95/max/stddev for total + TTFB, CSV export, and a keep-alive toggle.

Getting started

1. Open the MG REST Client view in the activity bar.
2. In Connection Profiles, click + to add a profile (server, config, credentials), then set its password/token via the key icon, and Set Active Profile.
3. In MG Operations, click an operation to open the request builder, fill in the fields, and press Send. Use ↻ next to Config to pick a server config.
4. Save… a request into a collection to build a reusable, runnable test suite.

(Developing the extension itself: npm install, npm run compile, F5 for the Extension Development Host, npm test for the unit suite.)

Connection profiles

Secrets are stored in SecretStorage and never written to settings.

Data-driven runs (experimental)

Run a request once per row of a data file (CSV or JSON), like Postman's Collection Runner and Newman -d. Off by default — enable mgRestClient.enableDataDrivenRuns, then right-click a saved request → "Run with Data File…" and pick a .csv/.json. Each row's values overlay the request's {{variables}}; results are recorded as one run with a per-row entry.

Creating the data file — columns/keys are exactly the {{variables}} you want to vary. Do not include connection variables (baseUrl, config, username, token — from the profile) or values captured at runtime. Only the business inputs go in the file.

CSV (header row = variable names):

newItem,newUM,productCode
MG-TEST-001,BOX,FG
MG-TEST-002,CASE,FG

or JSON (array of objects):

[
  { "newItem": "MG-TEST-001", "newUM": "BOX",  "productCode": "FG" },
  { "newItem": "MG-TEST-002", "newUM": "CASE", "productCode": "FG" }
]

Remember the file per request (optional): add "dataFile": "data.csv" to the request's _mg block (path relative to the collection) to skip the prompt; add "iterationCarry": true to carry captured variables across rows.

In CI — export the collection (Export Collection, which strips _mg but keeps the request + assertion/capture scripts) and run the same data file with Newman:

newman run my.postman_collection.json -d data.csv \
  --env-var "baseUrl=…" --env-var "config=…" --env-var "username=…" --env-var "password=…" \
  --reporters cli,junit --reporter-junit-export results.xml

Note: "Run with Data File…" iterates the selected request; newman run … -d iterates the whole collection once per row. Per-request config overrides apply in the extension only; Newman uses the single {{config}} variable.

Bundled sample

On first install the extension adds a sample collection to Test Collections as a reference (mgRestClient.includeSampleCollection, default on). Removing it from the tree is permanent — upgrades won't re-add it. Re-add anytime with MG: Add Sample Collection.

Collection JSON schema

Editing a *.postman_collection.json file gives validation + autocomplete for the extension's _mg metadata (operation, assertions, captures, baseline, per-case config, dataFile, iterationCarry) wherever it appears. The schema is additive — standard Postman fields are never flagged.

Commands

Settings

Security notes

• "Skip TLS verification" disables certificate checking for that profile — use only on trusted internal networks.
• Tokens and passwords live in SecretStorage and are never echoed to the webview or logs.
• Export Collection strips the extension's _mg metadata (including saved baselines) so shared files don't leak response snapshots.
• The webview uses a strict Content-Security-Policy with a per-load nonce and loads no remote content.

Accessibility

Modals are exposed as dialogs (role="dialog"/aria-modal) with focus moved into them on open, Tab trapped inside, Escape to close, and focus restored on close. Tab strips use tablist/tab/tabpanel roles with aria-selected kept in sync for screen readers.

Design

See design/DESIGN.md and design/TASKS.md in the source tree.

Limitations

• OAuth 2.0 / ION API handshake is not performed (paste a bearer token manually).
• Postman pre-request and test scripts are not executed on import; only variable substitution + the request (the extension generates assertion/capture scripts on export for Postman/Newman).
• Per-request config overrides and response baselines are extension features; in Newman the single {{config}} variable applies and baselines have no equivalent.