HTTaP is a sub-protocol of HTTP1.1 designed to access hardware resources (and more) with a browser-friendly interface.
It is initially designed to provide (trusted) connexion to a device (either hardware or software), on the same computer, or next to it, or on the other side of the planet.
The device can be real, emulated or virtual as long as the same set of messages are recognised.
HTTaP is designed for use in a lab, in a controlled environment with no outside connexion. Safety, encryption and authentication are not part of this protocol, which must not be used in other situations. Therefore it can be a basis for "IoT" devices but it is not a definitive solution.
HTTaP uses a reduced subset of HTTP, keeping only a few essential features.
Any HTTP compliant server must be able to understand HTTaP requests even though it can't fulfill all the requests
Any HTTP client can send a HTTaP compliant request with minimal effort. Normally, the HTTaP client is a classic web browser but wget or curl must work too.
HTTaP servers work mostly like classic HTTP servers but differ in a few ways, such as
resource reference (naming conventions)
serialisation (no simultaneous/multiple accesses)
These implementation choices come from constrains in size, speed, complexity : HTTaP must run in "barebone systems" with limited code and data memory, reduced CPU resources and lax security.
The HTTaP server must be as lean and simple as possible.
One source of complexity is removed by not interpreting the client's request headers. Actually, none of these headers are pertinent or relevant to HTTaP's use cases. This cuts a lot of work but also means there is no support for cookies. Standard authentication is impossible so HTTaP is unsecured. Any client can connect and use the resources at will. Use HTTaP only on airgaped networks.
Another source of complexity comes from the HTTP "vocabulary" : the only supported methods are GET, PUT and HEAD. * GET reads resources (files or dynamic variables) like any usual request. * PUT writes these variables (file upload is only an option) * HEAD is a requirement of HTTP1.1 and only minimal support is provided.
The server is single-threaded * This ensures by design that there can be no race condition. * The server is typically used by only one client at a time. * This reduces code complexity and timing issues * Raw performance and throughput are not critical, since the client and server are usually located next to each other
A HTTaP server typically contains two separate domains:
a static files server (a basic HTTP server)
a dynamic sever
The URL defines which domain is accessed with a very simple method : static files use standard URLs while dynamic ones start with the "?" character.