HTTP Server & Client

No server or web services backend would be complete without an HTTP interface. Hyperware can both create and serve HTTP requests. As a result, Hyperware apps can read data from the web (and other nodes), and also serve both public and private websites and APIs. The HTTP server is how most Hyperware processes present their interface to the user, through an authenticated web browser.

The specification for the server and client APIs are available in the API reference. These APIs are accessible via messaging the http-server:distro:sys and http-client:distro:sys runtime modules, respectively. The only capability required to use either process is the one to message it, granted by the kernel. It is recommended to interact with the http-server and http-client using the hyperware_process_lib

WebSocket server/client functionality is presented alongside HTTP.

At startup, the server either:

  1. Binds to the port given at the commandline, or
  2. Searches for an open port (starting at 8080, if not, then 8081, etc.).

The server then binds this port, listening for HTTP and WebSocket requests.

You can find usage examples here. See also kit news chat with GUI template which you can create using

kit new my-chat --ui

Private and Public Serving

All server functionality can be either private (authenticated) or public. If a given functionality is public, Hyperware serves HTTP openly to the world; if it is authenticated, you need your node's password so that your node can generate a cookie that grants you access.

Direct and Indirect Nodes

Since direct nodes are expected to be accessible over IP, their HTTP server is likely to work if the bound port is accessible. Note that direct nodes will need to do their own IP/DNS configuration, as Hyperware doesn't provide any DNS management.

Indirect nodes may not be accessible over IP, so their HTTP server may or may not function outside the local network.

Get Help: