We're building the public API now. We want it to be stable, well considered and shaped by real needs, so we're asking for your input: what you're building, which endpoints you'd call, and what would make Hypermass fit your systems.
What the public API will include
- Everything the CLI uses. The CLI is open source and talks to Hypermass through the same endpoints you'll be able to call: authentication, the WebSocket info channel that announces new payloads, download, and publish.
- More endpoints where they make sense, such as listing, searching and account actions, guided by your suggestions and requests.
Where the CLI fits The CLI is the on-ramp: the quickest way to publish or subscribe to a basic stream, with retries and recovery handled for you. Some of the stream types we have planned will be published and consumed through the API directly, so the API is central to where Hypermass is going.
Get involved Tell us what you need on Discord or in a GitHub issue. The blog will announce the API v1 release.
Hypermass API
The Hypermass API lets you publish, manage, and subscribe to data streams directly. We recommend giving the CLI a try initially because it handles failure, recovery and so on for you. The CLI documentation can be found here and is intended to be run in both local, dev and production environments as a simple link to Hypermass.
If you need something more advanced, the API is the right way to go. For example;
- only fetching data when you need it
- dynamically subscribing to streams
- listing, searching and account actions
The trade-off is that you'll have to handle much of the subscription logic in your code, and bear the burden of refactoring for future API changes (we will communicate these changes and try to be considerate with upgrade pathways).
No Library (yet)
If you're interested in the reasoning, please see our detailed article CLI Design Rationale.
We have guidance notes on how to integrate popular languages to the CLI; Building a Client.