POST /UA/URL
WHILE( DISPLAY ) { GET /UA/UPDATES ; PUT /UA/CHANGES ; }
DELETE /UA/URL
Where UA is the User-Agent, or the basic hypermedia "canvas" (for this example think apropos Mozilla, XUL, Chrome, etc) with user credentials. The POST line describes the action that opens the URL as the new tab. The WHILE line describes the action of page display, updates, and user actions. The DELETE line describes the action that closes the tab.
When someone enters any URL into the "URL bar" (or Address bar) then the POST line is given.
The DISPLAY is some context from the window manager or display device. There are various ways on how the display context connects with the UA context in some form of canvas for content and user interface. The GET (polls) updates (for) the canvas from the context and the PUT relays the actions in relation to that canvas.
That's the basic flow, yet any conveyance of that is conceptually hard. We can measure how hard by how often and similar the popular applications want any return to that basic flow. When there are multiple pages, canvases, users, regions, and etc then there are conceptual issues on how to frame them in regards to synchronization.
How ReSTful depends on the frame rate. Think of those old B&W TVs where frame rate depends on NTSC or PAL, and the static screen shows the bitstream resolution. NTSC could hold 10Hz worth more than PAL, and that could be equivalent to the separation between the header tag and body tag. Then the channel selection is the POST/DELETE cycle. Within the10Hz is something like the QR code(s), and the other 50Hz per frame is the DISPLAY screen (which further nests in QR codes with multiple alignment).
 |
| Test pattern from blog titled Cold War Punk |