...
In this discussion we should make a decision - will this situation impact our current solution?
Solution
Requirements from Iurii Vinogradov
We need Http compatible interface on Iroha side
We need and Http compatible client library which can support all Iroha user ISI, Query, streams.
HTTP client library should be implemented in Rust for use from Substrate.
We need JS compatible library to interact with Iroha2
The deadline is the middle of August.
Mobile developers has a lot of concerns about usage of `Rust` parts in their codebase, so it looks "native" to provide only HTTP API for 2.0.0 release and give a full freedom about implementation to client-side developers.
Solution
Which can be rephrased as:
- Iroha should provide HTTP API for:
- Iroha Special Instructions Submission
- Iroha Queries Execution
- Iroha Cloud Events Consumption
- Iroha's Rust HTTP client library for Substrate's Off-chain Workers should be developed
- MIME type of the HTTP API will be `application/scale`
- Clients build their own functionality or use 3rd party clients to establish HTTP connection, sign and construct of transactions and work with SCALEIroha's JS client library should be developed
Decisions
- Iroha HTTP module `iroha::modules::http` will provide additional HTTP Endpoints on top of existing Torii Endpoints, developed as a part of bridge and DEX features from the business point of view.
- `/transaction` for incoming transactions requests
- `/query` for incoming queries requests
- `/config` for health check, monitoring and maintenance API
- JS library will use HTTP Endpoints and will not depend on Iroha codebase
- Rust HTTP Client will be implemented as a separate `no-std` cratenot be implemented
- Cloud Events will be implemented via HTTP instead of WebSocket in addition to WebSockets because of Substrate's restrictions
...