Synadia Platform
HTTP Gateway
A first-class RESTful interface for NATS. The HTTP Gateway is a stateless component which can be added to any NATS system managed by Control Plane
Getting started
Before deploying your own HTTP Gateway you may want to familiarize yourself with API Token management and the API usage in Synadia Cloud. The HTTP Gateway is supported in the free tier subscription.
You can find more usage examples in the preview announcement at HTTP Gateway preview announcement.
If the HTTP Gateway fits your requirements jump to the deployment instructions.
Supported NATS functionality
As of June 2024 the following are supported:
- Key/Value Store
- Management
- Access
- Object Store
- Management
- Store Access
- NATS Core
- Publish and Subscribe (experimental)
- Request/Reply (experimental)
- Including access to NATS micro services
API example
curl -H "Authorization: Bearer <API_TOKEN>" \
https://<your gateway>:<port>/v1/kvm/buckets
Check the full API documentation for details.
Check here for features and architecture.
Why would you use the HTTP Gateway?
For those who are familiar with NATS' native WebSocket support and client library, you may be thinking why is HTTP Gateway necessary?
An important distinction between NATS and HTTP, is that HTTP is inherently designed to have stateless interactions between the client and server. For example, a request against an API that returns a JSON representation of a resource. The connection only needs to exist for the duration of that exchange. There are certainly optimizations to amortize the setup cost of the connection such as keep-alive and pipelining many requests for assets, but the model is a once-and-done exchange.
NATS, on the other hand, was designed for long-lived connections enabling high-throughput and low-latency M:N exchange of messages and data and the choice of synchronous or asynchronous interactions. Supporting WebSockets as a transport enabled running a NATS client in the browser, but it still assumes a long-lived connection.
The two predominant motivations driving the development of this component were:
- enabling access to NATS data services (key-value and object store) and invocation of NATS microservices on the backend via an HTTP API
- acknowledging there are constrained environments where only an HTTP client is available and there is no ability to install a NATS client
The outcome we wanted was a first-class HTTP interface to NATS without needing to explicitly learn NATS or use a NATS client.
However, being powered by NATS within Synadia Cloud means data and services can be transparently accessible across all major geos, the three major cloud providers, and out to an edge you define without any additional infrastructure or integrations.