Description
-
- Why
https://jmap.io/spec-core.html#references-to-previous-method-results
To allow clients to make more efficient use of the network and avoid round trips, an argument to one method can be taken from the result of a previous method call in the same request.
Example:
[[ "Foo/changes", { "accountId": "A1", "sinceState": "abcdef" }, "t0" ], [ "Foo/get", { "accountId": "A1", "#ids": { "resultOf": "t0", "name": "Foo/changes", "path": "/created" } }, "t1" ]]
`back references` that mean server will reuse the result of a previous method call in the same request.
Process is:
- When processing a method call, the server MUST first check the arguments object for any names beginning with *#*.
- If found, the result reference should be resolved and the value used as the “real” argument.
- If any result reference fails to resolve, the whole method MUST be rejected with an *invalidResultReference* error.
- If an arguments object contains the same argument name in normal and referenced form (e.g., foo and #foo), the method MUST return an *invalidArguments* error.
A *ResultReference* object has the following properties:
- *resultOf*: String The method call id (see Section 3.1.1) of a previous method call in the current request.
- *name*: String The required name of a response to that method call.
- *path*: String A pointer into the arguments of the response selected via the name and resultOf properties. This is a JSON Pointer, except it also allows the use of * to map through an array (see the description below).
-
- How
https://github.com/linagora/james-project/pull/3683 demonstrated a proof of concept doing JSON substitution within the method arguments (relying on play-JSON JSON transformers) before the actual processing start
This makes back-reference resolution completly orthogonal to the Methods being written.
-
- Definition of Done
Write some simple memory integration tests demonstrating back-references are resolved. Also test back-reference resolution failure.