Introduce mechanism for request/response synchronization of some client inputs

[KtorZ]

Why

Some server outputs are immediate consequence of client inputs. In a certain way, they are synchronous requests made asynchronous because of the underlying transport mechanism that we use (namely, WebSockets). However, there are numerous cases where relying on the synchronous nature of those request would be handy. In particular, it can be hard for a client to determine to which request does a certain response correspond to (and it's never been stated that the server effectively process requests sequentially).

What

There are mainly two complementary solutions to this problem.

1. Allow a mirror or echo parameter to be passed with some client inputs (e.g. GetUTxO) such that when set, it is also returned as part of the corresponding response. This would allow clients to set some state, token, id or whatever they need to handle responses with more ease.

2. Provide a synchronous HTTP API for some basic request/response queries such as GetUTxO. The full list of endpoints is yet to be identified.

[ch1bo]

Do you want to do 1 and 2 or only one of them? If only one, we should decide which before planning this as a feature

[KtorZ]

I want to discuss the idea first ^.^. As I said, both are complementary, and perhaps (1) is a bit more powerful / flexible than (2) and also less of a hassle to implement for us (thus, a good one to be tackled first).

[matiwinnetou]

+1, exactly we are hitting those issues now.

[satran004]

+1 We have exactly same requirement for GetUTxO query.

[ch1bo]

You can use a reaction on the original post or in the discussion overview to upvote this.