Although not exactly protocols, this page lists tutorials that also include libraries not included in the core libraries. You have many options for browser-to-server communication and for sending asynchronous, real-time data from the server to the browser. Names such as REST, AJAX, and RPC are often variations on the same basic idea: a browser sends a request, the server runs logic, and the browser updates the UI with structured data.
The practical difference is how you move messages back and forth: plain HTTP form posts, Fetch-based "AJAX" calls, persistent WebSockets, or a publish/subscribe layer like SMQ for real-time updates. The links below walk through each option, from beginner-friendly fundamentals to high-performance patterns.
Tip: If you are building a UI for devices, especially with TLS enabled, connection setup and round-trips matter. WebSockets and SMQ can feel much more responsive than repeated HTTP requests.
Start here if you want the simplest mental model: the browser submits a form using a normal HTTP POST, and the server responds by generating the next page (or a result page). This is the "plain old web" flow.
This moves you from "submit + reload" to "request + update the DOM". The browser sends data with Fetch (often JSON), the server returns JSON (or small HTML fragments), and you update part of the page without a full refresh. Same idea as forms, just smoother UX.
Fetch-based AJAX opens a new HTTP request for every call. WebSockets keep one connection open, so you can send messages both ways with low overhead. This tutorial shows an "AJAX-like" pattern implemented on top of a persistent WebSocket connection, so you keep the same mental model while getting faster interactions, especially noticeable on embedded devices when TLS handshake costs matter.
SMQ is a publish/subscribe protocol with additional features such as sender identity and targeted messaging. Although it is positioned for IoT and device management, it is also a practical way to push live data from server to browser for dashboards, alarms, status streams, multi-client synchronization, and instant UI behavior without polling.
If what you really want is "call a server method and get a result," RPC is a clean mental model. This example provides client and server libraries for doing RPC over SMQ, which is much faster than repeated HTTP calls and pairs nicely with real-time UIs by using the same channel for calls and events. The performance improvement is especially noticeable on embedded devices, where TLS handshake costs can be significant.
REST really shines when your "client" is software: another device, a gateway, a cloud service, or a test rig. You model capabilities as resources (URIs), use standard verbs (GET/POST/PUT/DELETE), return JSON, and rely on status codes. This tutorial shows a compact, practical REST design in Lua on top of BAS.
If you're unsure which path to pick:
A good progression is to begin with plain HTML forms, then adopt Fetch and AJAX for a more responsive user experience. As requirements grow toward real-time updates, multiple active browsers, or reduced connection overhead, WebSockets and SMQ become the natural next step.