Add http endpoints for rpc functions

[leighmcculloch]

What

Add http endpoints for each of the rpc functions that the rpc serves so that a simple curl command can be used to interact with the RPC on the commandline.

Why

JSON-RPC is very inconvenient to use on the command line with curl, which increases the barrier to entry with hacking against the RPC API.

This has been suggested ~3 times I think by different people.

Ideas have been suggested about building utility CLI tools just to fill the gap.

It could be argued that maintaining two APIs is something that we should avoid, but maintaining an API plus additional tooling is a similar cost anyway.

cc @kalepail @fnando @dmkozh @Shaptic @janewang

[leighmcculloch]

An example of a possible HTTP API and mapping to the existing rpc functions:

• GET /health -> getHealth
• GET /version -> getVersionInfo
• GET /network -> getNetwork
• GET /events -> getEvents
• GET /ledger -> getLatestLedger
• GET /ledger-entries?key[]=xdr&key[]=xdr -> getLedgerEntries
• GET /transaction?hash=txhash -> getTransaction
• POST /transaction?tx=xdr -> sendTransaction
• POST /simulate?tx=xdr -> simulateTransaction

To learn from Horizon's success stories too, we could include something like:

• GET / -> returns a JSON "table of contents", similar to Horizon

[2opremio]

This goes way back. I was personally against using RPC but it was a conscious decision.

See: https://discord.com/channels/897514728459468821/1097914661933948938/1097914661933948938

We definitely shouldn't support both and I don't think we should switch now unless we deem it critical.

[dmkozh]

Just my 5c: I don't think that fully replicating the RPC interface is necessary, but the key endpoints, such as health and version are more useful as GET methods. I wouldn't anticipate these to be used much by the RPC clients (if at all); these are likely much more useful by humans, e.g. to determine the RPC version when troubleshooting the issues. Generic HTTP API like this is not unheard of for the RPC services (at least from my experience), so I don't see this being an architectural problem. But I agree that in any case that's probably not the highest priority.

[sreuland]

there is a partially overlapping feature request, soroban-rpc/148 which asks for similar plain HTTP/GET for some endpoints, specifically for getHealth since monitoring tools commonly have a http client config that works for HTTP/GET.

[leighmcculloch]

We definitely shouldn't support both

@2opremio What downsides do you see for supporting both?

[leighmcculloch]

I don't think that fully replicating the RPC interface is necessary, but the key endpoints, such as health and version are more useful as GET methods.

At a minimum I think we need these three:

• GET /health -> getHealth
• GET /version -> getVersionInfo
• GET /network -> getNetwork

But I've used most of the endpoints on the command line, all except the events endpoint, and when hacking on the command line JSON-RPC is inconvenient, awkward, etc. If we aren't going to expose a HTTP API for them all then I think the CLI will end up getting commands for interacting with them. But it is less cross-functional maintainership, and addressing the problem at the source, if we add a HTTP API to the RPC.

[leighmcculloch]

An alternative is we help people select good tools to use instead of curl, such as httpie or xh or httpie-go, that make interacting with a json-rpc server more enjoyable.