RESPONSE JSON AS $var dropped on REST client roundtrip

[ako]

Problem

RESPONSE JSON AS $var declared in CREATE REST CLIENT is dropped on roundtrip. After write/read, DESCRIBE REST CLIENT emits an empty RESPONSE JSON AS ; clause.

Reproduction

CREATE REST CLIENT MfTest.RC_TestApi
BASE URL 'https://httpbin.org'
AUTHENTICATION NONE
BEGIN
  OPERATION PostJsonTemplate
    METHOD POST
    PATH '/post'
    BODY JSON FROM $JsonBody
    RESPONSE JSON AS $Result;
END;

After mxcli exec then mxcli -c "DESCRIBE REST CLIENT MfTest.RC_TestApi":

  OPERATION PostJsonTemplate
    ...
    BODY JSON FROM $JsonBody
    RESPONSE JSON AS ;        ← variable name lost

Root cause

Mendix does not store the response variable on the operation document. Rest$NoResponseHandling (and Rest$ImplicitMappingResponseHandling) only carries ContentType — the actual variable binding is on the call site (the Microflows$RestOperationCallAction.OutputVariable field), not on the operation definition.

Our model.RestClientOperation.ResponseVariable field is therefore inherently lossy when the operation is read back from BSON.

Suggested fixes

Pick one of:

1. Drop the placeholder from DESCRIBE output when ResponseVariable == "". Print RESPONSE JSON; (no AS) instead of RESPONSE JSON AS ;. This keeps DESCRIBE re-executable, at the cost of users losing the variable name suggestion when they edit a DESCRIBE'd client.

2. Synthesize a default variable name like $Result on the read path so DESCRIBE always emits a valid AS $Result. This is lossy but produces clean MDL.

3. Treat RESPONSE JSON AS \$var as call-site-only and remove it from the operation grammar entirely (breaking change — existing CREATE REST CLIENT scripts would need updates).

Option 1 is the smallest change. Option 2 gives prettier output. Option 3 is the most "correct" but most invasive.

Context

Discovered while verifying #161 / #162 work and the BODY JSON FROM \$var roundtrip fix in commit 4000f8b. The body fix uncovered that RESPONSE has the same surface symptom but a different (deeper) cause.

[github-actions]

Issue Triage

Summary:
The issue reports that the variable name in a RESPONSE JSON AS $var clause is lost when a REST client definition is written and then read back with mxcli.

Checklist for bug report completeness

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	❌	Not mentioned
Scenario (what the user was trying to do)	✅	Creating a REST client, running mxcli exec, then DESCRIBE REST CLIENT
Expected output	✅	RESPONSE JSON AS $Result; (variable name preserved)
Experienced output	✅	RESPONSE JSON AS ; (variable name missing)
AI bug report (session log or mxcli diag --bundle)	❌	Not provided

What’s missing:
Please add the output of mxcli --version (or the commit/build you’re using) and the Mendix version of the project you’re working with. If possible, also attach a session log from mxcli diag --bundle (or at least the relevant log excerpt) so we can reproduce the environment.

Thanks for the detailed report—adding the above information will help us investigate and fix the round‑trip loss quickly!

---

Automated triage via OpenRouter — workflow source