Page History

...

• 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
• Iroha's JS client library should be developed

Decisions

• Dedicated Iroha Bridge HTTP module will provide additional HTTP Endpoints on top of existing Torii Endpoints
• JS library will use HTTP Endpoints and will not depend on Iroha codebase
• Rust HTTP Client will be implemented as a separate `no-std` crate
• Cloud Events will be implemented via HTTP instead of WebSocket because of Substrate's restrictions

Alternatives

• Iroha provides HTTP API out-of-the-box
  • Need to define scope
  • Need to not duplicate peer to peer communications logic
• Dedicated HTTP server module on Iroha 2 not included in the core but have an ability to proxy all ISI and queries if needed.
• Iroha Bridge has an additional application as a proxy on top of Iroha API (as a standalone app or service mesh)
• Every client is responsible for HTTP Adapters

Concerns

• Any change in `iroha_network` algorithms and Iroha entities format will break clients
• HTTP implementation of Cloud Events may be very slow and impact the throughput of the whole ledger

Assumptions

• Bridge clients will use Substrate's Off-chain Workers with an ability to communicate over HTTP only
• JS client has additional restrictions
• All clients will use scale encoding

Risks

• Backward compatibility breakage `[7; 9]`
• Performance regress `[8; 5]`
• Scale encoding will be hard to implement for non-rust clients `[3;5]`

...