Yann Guidon / YGDESThis page contains a draft for a uniform/universal URI layout and "vocabulary" that all applications/clients can use. As usual, only stable code will serve as a reference, this page is more of a reminder and declaration of intention.
HTTaP defines two "domains" :
- The static domain contains files that do not change. They usually contain all the HTML/CSS/JS interface and all the support files. They are usually cacheable.
- The dynamic domain is introduced with a « URI with query component(s) », starting with "/?", to prevent them from being stored in cache (in addition to having appropriate headers).
The dynamic domain is split further:
- lowercase names are usually reserved for standard HTTaP features (such as ping or loopback)
- UPPERCASE names describe application-specific resources, signals, like memory, registers, sensors...
I'm not sure about the following paragraph:
Signals use the object notation (with a dot) to represent hierarchy. As a rule of thumb, if it uses a copy of the circuit or an instance of the code, it will be dot-represented. They will be treated similarly by the handler of the server, for example memory spaces...
| URI | comments | GET | POST |
| /path/filename | Static file to serve. | * |
|
| /? | Root of HTTaP, serve a JSON-formatted list of available of valid dynamic resources names | * |
|
| /?ping | A simple key used to keep the connection alive. Returns the number of seconds before the link is closed. Note: the ping keyword can be followed by any character, to help with caching servers. |
* | |
| /?invalid | Never decoded, always returns an error (if you want to close the session for example) |
||
| /?loopback | Loopback for JS save/restore (optional) | * | |
| /?list | (for signals) Return the list of the signals and their hierarchy |
* | |
| /?changes | (for signals) same as /?list but only include signals that have changed |
* | |
| /?REG | read the value of all the registers | * | |
| /?REG/R1 | read the value of register R1 | * | |
| /?REG/R1,R2 | read the values of registers R1 and R2 (optional?) | * | |
| /?MEM | Dump the contents of the memory | * | |
| /?MEM/123-456 | Dump the contents of the memory from locations 123 to 456 | * | |
| /?IO.SPI.1/ | Read the full status of the first SPI port | * |
The uppercase names are just examples and are only suggestions.
I'm not sure about the representation/formatting of ranges but they are useful to reduce the bandwidth and CPU load.
Memory ranges should use the #HYX file format to save bandwidth, compared to plain JSON syntax.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.