You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The website should be the host of the button displayed for public links to commands.
We need a page similar to /service, /device, and /devices that shows a button if the public link is valid.
Visual representation is the website's role, not the REST interface's.
Currently, the REST interface just throws some html at the browser when it receives a GET on a command public link. The button it generates is set to make a return POST on itself, which require the REST interface to have an understanding of it's absolute address (with version, like /apiv1).
The website is where we set which api version/backend we want to use. This key abstraction breaks when a certain REST interface version is exposed alongside the website (in order to present the command link button).
The text was updated successfully, but these errors were encountered:
To save cycles later, here is the proposed scheme:
The website should hooks requests for public links using a URI like https://openchirp.io/publiccmd/<link_id> and displays a button if that link is valid (after rest request)
The REST interface hooks GET and POSTs using it's original URI scheme (https://openchirp.io/pc/<link_id>). POSTs, as before, launch the command, but GETs simply retrieve info about the link (mainly just for validation purposes).
The website should be the host of the button displayed for public links to commands.
We need a page similar to
/service
,/device
, and/devices
that shows a button if the public link is valid.The text was updated successfully, but these errors were encountered: