Are we content with current RPC/API?

[Jonathan Silverblood]

I've been working for the last weeks with things that have required me to use the bitcoin RPC and it has to been frustrating at times. Has there been any work/discussion with regards to restructuring the RPC?

If this has not been up for discussion before, what qualities and requirements should be considered when designing a new interface?

If it has been discussed before, can someone point me in the right direction so I can read up and learn a bit about it?

Also want to say that I am happy what currently exist is there and that I can work with it and I appreciate all the work it has taken to get us to the current state - just pondering if we could better support application developers if we had a more feature complete, performant and documented API access.

 

[Erik Hedman]

Didn't @Tom Zander try to do write an alternative to the current RPC, or am I totally mistaken?

 

[Jonathan Silverblood]

I don't know, but BCHD has two interfaces and Verde has an entirely new interface as well. The old bitcoin RPC structure is probably fine, but I think we really should look into specifying a complete, coherent set of RPC calls.

Not much response here though, so I guess this would be a "build it and they will come" situation at best.

 

[Christoph Bergmann]

Maybe you outline how you'd wish to change the rpc, or tell, what frustrated you most

 

[Jonathan Silverblood]

@Christoph Bergmann I've already gotten the changes I need for the moment (https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/1575), this is more of a discussion on how, if at all, we could improve upon the bitcoin RCP if we were to build something new.

 

[theZerg]

I would support an effort based on flatbuffers (https://github.com/google/flatbuffers). Although before making it comprehensive we should experimentally validate that the high performance the flatbuffers architecture ought to have really exists.

I think that people have talked about protobufs RPCs for a while. No actual progress though. Its a matter of engineering effort verses the json RPC being "good enough", especially for the tx loads we have today.

 

[Jonathan Silverblood]

This might be something that's worth attention:

https://github.com/gcash/bchd/blob/grpc-spec/docs/grpc_api.md

 

[Tom Zander]

@Jonathan Silverblood As Erik stated, in Flowee I've been looking at APIs for a while. As a little unknown background, I worked with Trolltech (later Nokia) on the Qt libraries. The saying there was always that the differentiating product we shipped were usable APIs. I've have that bug and it gives me pleasure to make good APIs...

One of the things I noticed is that there are two approaches to APIs which really stem from actual usage. One is something like the JSON stuff and they use a REST API. The natural consequence of such an API is that each individual call has to contain the maximum amount of data because the overhead (setting up a connection, authenticating etc etc) is massive.

We see this in the current JSON apis. The GetHeader [hash] call shows a lot of details that are not part of the header at all, but may be useful in a small percentage of calls.

All this shows that the JSON API is not meant for high volume. It has massive amounts of overhead in all parts.

I do agree with the bchd devs about using grpc for all these points above.