Barix Flexa Overview
The Barix Flexa System is a versatile application management system for Barix devices.
Barix products are used for many different applications, and both audio as well as control products use the Flexa architecture and services to allow a customer to install an application easily.
From a user view
- the user purchases a Barix device with Flexa Firmware
- he identifies the device by its "regID" - a unique, random identifier associated with the device
- he goes to a web portal and registers the device for that specific application using the regID.
- optionally (depending on portal and application), the user might configure the application there as well.
Once the user has registered the device on the portal, the flexa magic happens, and when the device boots, it will find the correct server, and load the application and optional parameters.
The device will then run the application, and it can also be disconneced from the internet.
portal dev need to contact barix to be set up as a partner
barix staff goes to flexa admin portal (admin.barix.cloud, by the way does not work yet) and creates the partner
partner need to confirm his email and set password. then log in to access his api key.
partner can use "his" login to see and revoke/reissue the api key, and to see all devices which are registered by his portal(s)
when customer goes to the partner portal, he registers the device with regid.
- customer portal registers the regid via api call on flexa registry, including at least the "portal URL" (and potentially some more fields which are for future expansion)
- a device can be de-registered either by calling the register api, but without providing a URL, or by going into the partner portal and manually deregistering the device.
when device reboots next time
- device contacts flexa registry with the regid to get the portal url (and maybe some parameters)
from here, the device only talks to the PORTAL api.
The portal api:
the portal url, when called (with regid), will provide, in json format
... the url to the zip file containing the app
... the version of the file
... and optionally (if those functions are supported by the portal !)=
- setStatus URL
- getConfig URL
- data URLs
while those above optional urls are used by the application code so this could all be done different, we encourage a special format so our provided examples can be easily used
well, i think the portal can allow multiple methods to access the api, but the answer of course is defined and same for all methods.
There is nothing wrong in being flexible and supporting both GET and POST methods, but then this must be consistant for all functions on that server/api
actually my example above was maybe not good. rather use http(s)://portal.web/api/register?regID=oeNd3+IdQlB9
but i think offering get and post with json as alternatives, why not. some may find one method better, not sure if any of them is more "secure" .. secure it is anyways only with https. then it does not matter if the parameter is i the url or in the body, i think