Hello,
Is there any node API document available for Cardano? Can anyone share the link?
I want block and transaction information from API.
2 Likes
Is this what you are looking for ?
https://docs.cardano.org/projects/cardano-node/en/latest/reference/cardano-node-cli-reference.html
No. This refers CLI.
I want APIs which we can run on our own node or on any public node. Those APIs I’ve to integrate with my application.
I want block information like block DateTime, block height, block hash, etc and transactions under that block which may include transaction hash, sender, recipient, balance, etc.
1 Like
Cardano-node does not have a REST API, but it does have a Haskell API for inter-process communication that is accessible through a local unix socket. You can access that socket from a remote machine using an SSH tunnel or a tool like socat, and it appears that dandelion.link offers a service to connect to their public node.
You would want to use cardano-db-sync for your own node. This will help you sync your node to a Postgres database, which in turn can be queried using API layer of your choice (cardano-graphql, cardano-rest or PostgREST ). For connecting to public APIs, you can use https://blockfrost.io or https://dandelion.link .
1 Like
Thank You!
As per my understanding cardano-db-sync will run on top of our local node only and graphql, cardano-rest, PostgREST are on top of cardano-db-sync.
So, without using cardano-db-sync, are there any API’s available which will communicate with node directly.
For e.g., cardano node is running locally and port 1234 is required to be opened then we will get the block information using below GET request http://localhost:1234/block?1.
1 Like
The API interfacing - unless you want to explore Protocol (IPC API) is not available from node, certainly not in the manner you’re looking for - as mentioned above.
Fine! Thanks for the information.
I’m also looking for this information, but I cannot find a non-Haskell way of talking to a Haskell IPC endpoint.
I had the same issue. I couldn’t get anywhere with the IPC. I couldn’t find any technical documents on it or the payloads, other than reading the source code for candano-node. I decided an easier approach is writing an ouroboros client in the language I want. I don’t know what the IPC would offer that an independent network client couldn’t do, other than deeply interacting with a specific node.
1 Like
I honestly do not understand the design philosophy here; there doesn’t seem to be any awareness of the Ops challenges to running a large number of validators (in this case, “producers”), and iohk is depending on the community to cobble together a bunch of very contorted hacks and workarounds for some questionable architecture decisions. Not much of that community effort seems to be going upstream at all.
2 Likes
I agree. The fact that most nodes are kept online by a pack of community developed shell scripts certainly raises my eyebrow. Actually running a node definitely involves some black magic and tribal knowledge. Thankfully these forums seems to be pretty generous in sharing that knowledge.
However, I do like the philosophy of the project which is why I’m sticking around and investing time and money into developing things.
1 Like
A related thing I find astonishing is that there’s been no public announcement or documentation of IOG’s own devops tools for the node:
I only found this because the node 1.26.1 release notes referred to these in “Steps to mitigate downtime.” Following that link suggests a nix script to backup a running node… something that would be universally useful for SPOs… without even a bit of context how to use that script or create a production environment in which those tools are available.
1 Like
@COSDpool wow, there is a ton of stuff in that repo. That’s a good find. There’s also stuff in there pertaining to auto-rotation of KES keys. I don’t know why this stuff isn’t being broadcast to the larger community.
1 Like
They should take a lesson from other protocols and provide an atomic snapshot mechanism that does not require stopping the node.
All this excess tooling that is not baked into the protocol or node itself just makes everyone re-invent the wheel, badly, everywhere a bit different and broken in different ways.
Nobody sane is going to build their own tooling off of nix.
No, cardano-node itself needs at least a few things baked into it, and not dependent on all this external tooling/hackwork
- reload topology w/o a restart
- rotate/reload KES keys w/o a restart
- a canonical JSONRPC endpoint (even if it is a JSONRPC/socket bridge) that the 700 line
envfile in the guild ops tooling can use query to get all the config info at once so it isn’t 700 lines long - take an atomic snapshot w/o stop/start
3 Likes
cardano-db-sync is not appropriate for either relays or producers.