HTTP interface to Fulcrum methods

[mainnet-pat]

We already have TCP (node only), WS (node+browser). Both require sophisticated software like elecrum-cash.

How about the simplest thing in the world of web - namely http way to issue direct requests to Fulcrum.

I understand, that subscriptions will not do any good with http, but SSE (server sent events) are also http only tech for subscriptions worth to evaluate.

I am aware that Chris Troutner offers his REST wrapper around Fulcrum, but it is an extra hosted dependency and is inferior towards my proposition.

[cculianu]

I definitely would like to support regular http. Currently Fulcrum does have an http/1.1 implementation internally. I am going to write down my thoughts on this here so that they are not lost. And maybe a curious reader can chime in with some solutions to the problems I will outline below with doing this. Basically, there are some engineering challenges associated with supporting HTTP though. As per the RFC for HTTP/1.1 https://datatracker.ietf.org/doc/html/rfc9112...

• HTTP/1.1 supports the notion of "pipelining". That is, clients can send multiple requests in a fast burst and not wait for a response before issuing the next request. This is great. Fulcrum also supports this! However:
  • Fulcrum typically returns responses in no particular order -- it responds to particular JSON-RPC messages coming in a pipeline out-of-order, as they are ready. This is ok on the application layer because clients are expected to reconcile requests and responses by JSON-RPC id parameter.
    • HOWEVER HTTP/1.1 requires that all responses to individual request arrive in-order. (See section 9.3.2 of the HTTP/1.1 spec.)
    • This requirement of HTTP/1.1 is at-odds with the design of Fulcrum and would require additional engineering on my-part to:
      1. Detect the Pipeline condition, and
      2. Guarantee that if a pipeline state exists in the client<->server connection, "delay" out-of-order replies in some buffering scheme such that when they finally go out to the client, the responses are in the same order that their corresponding requests were in when originally submitted to the server.
• Additionally, HTTP/1.1 seems to forbid asynchronous "notifications" -- that is, every response needs to have a request associated with it. I am not sure how to do JSON-RPC 2.0 "notifications", since they would require HTTP/1.1 to support a request-less asynchronous "Response" -- which is explicitly forbidden by the HTTP/1.1 specification (see section 9.2 of the HTTP/1.1 spec.).
• I am aware of SSE (server-sent events) which is more of an HTML5 JavaScript-level specification for how to receive asynch events from a server.
  • I have to look into the mechanics of how this is actually implemented. I suspect it requirest HTTP/2.0 which does support request-less responses, streaming, etc.

Anyway these are my thoughts on the topic. It's an onion and while seemingly an easy addition to Fulcrum, it does require more investigation and research to implement, sadly.

It may ultimately require HTTP/2 which ... is complicated and IIRC isn't even a fully accepted specification even now in 2023 (even though in practice it basically is accepted since all browsers support it). :(

[mainnet-pat]

what if we restrict http version of fulcrum to http v1 and do not support subscription methods? also initial protocol version negotiation can be done with http headers.

I've been asked about "BCH official json rpc" once again

[rnbrady]

One Electrum request per HTTP request and per connection.
For subscriptions use SSE, which should automatically disable pipelines.
For all other requests Connection: close which should disable pipelines.