OpenApi Definition for Electrs Rest Api

[cjrutherford]

Fully validated requests with the exception of the broadcast and tx routes to post a transaction to the chain.

everything else has been documented with the correct shape of the response.

work on request body is dependent on testing of the broadcast and tx routes as mentioned above.

all other routes tested properly.

[RCasatta]

I like the OpenAPI spec, Ideally we should have some automatic way of checking it's in sync with the real API. This seem not quickly doable but IIRC you can build "tester web site " out of the spec, can we expose/have instruction to build it locally so that at least one can manual test it?

There is some naming confusion I would fix, like btcd instead of bitcoin in the file name (btcd recall a different software, the node written in go) and also a typo in the commit message (lnd instead of liquid)

[philippem]

see comments about similar description above

[philippem]

link is 404

[cjrutherford]

it appears that the entire glossary section is gone looking into alternatives.

[cjrutherford]

found the right docs: https://btcinformation.org/en/glossary/merkle-block

[philippem]

type "merkelblock"

[philippem]

this response content has been swapped for merkle-proof.

The merkle-proof resource is a hex string, whereas merkle-block-proof is the electrumx object

[cjrutherford]

swapped them around and confirmed response schemas

[philippem]

see comments above

[philippem]

I like the OpenAPI spec, Ideally we should have some automatic way of checking it's in sync with the real API. This seem not quickly doable but IIRC you can build "tester web site " out of the spec, can we expose/have instruction to build it locally so that at least one can manual test it?

There is some naming confusion I would fix, like btcd instead of bitcoin in the file name (btcd recall a different software, the node written in go) and also a typo in the commit message (lnd instead of liquid)

I like the OpenAPI spec, Ideally we should have some automatic way of checking it's in sync with the real API. This seem not quickly doable but IIRC you can build "tester web site " out of the spec, can we expose/have instruction to build it locally so that at least one can manual test it?

There is some naming confusion I would fix, like btcd instead of bitcoin in the file name (btcd recall a different software, the node written in go) and also a typo in the commit message (lnd instead of liquid)

we can do a validation with a generated client (e.g. https://openapi-generator.tech/)

[cjrutherford]

I like the OpenAPI spec, Ideally we should have some automatic way of checking it's in sync with the real API. This seem not quickly doable but IIRC you can build "tester web site " out of the spec, can we expose/have instruction to build it locally so that at least one can manual test it?
There is some naming confusion I would fix, like btcd instead of bitcoin in the file name (btcd recall a different software, the node written in go) and also a typo in the commit message (lnd instead of liquid)

I like the OpenAPI spec, Ideally we should have some automatic way of checking it's in sync with the real API. This seem not quickly doable but IIRC you can build "tester web site " out of the spec, can we expose/have instruction to build it locally so that at least one can manual test it?
There is some naming confusion I would fix, like btcd instead of bitcoin in the file name (btcd recall a different software, the node written in go) and also a typo in the commit message (lnd instead of liquid)

we can do a validation with a generated client (e.g. https://openapi-generator.tech/)

should I create a generated client and set it up to auto test?