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
There was a good point made about how having an API which allows remotely managing sites in Panopticon might serve some automation use cases where, presumably, using the CLI through Ansible or similar is not convenient / practical.
Some preliminary thoughts below.
Authentication
For practical reasons, it makes sense to use a variation of the FOF / Joomla API authentication scheme. Instead of having a single token per user we can allow the user to create multiple tokens which can be enabled/disabled, reset, and can also have descriptions, and an expiration time (if desired).
Endpoint
It makes sense to have a separate /api application than trying to reuse the main Panopticon application.
Do note that we can still access the main Panopticon application's container by instantiating it. This allows us to use the main models in the API.
API features
The features which make sense to have are:
Sites
List sites (GET)
Get a site's configuration (GET)
Add a site (PUT)
Modify a site (POST)
At this stage it does not make sense managing users, tasks, and queues.
The text was updated successfully, but these errors were encountered:
If this would mean having APIs that can be used by an external application (another Joomla site for example) to get Panopticon data that would be AWESOME! For example, all the data relating to a site such as php version, Joomla! version, extensions to update, etc., would be really fantastic.
@morphinestyle Yes, you could do that, eventually. At first, I want to make it possible to remotely create and remove sites in Panopticon. The use case I have in mind is the discussion I have already linked: someone creates a site with an automated tool, and they want to start monitoring it right away.
There was a good point made about how having an API which allows remotely managing sites in Panopticon might serve some automation use cases where, presumably, using the CLI through Ansible or similar is not convenient / practical.
Some preliminary thoughts below.
Authentication
For practical reasons, it makes sense to use a variation of the FOF / Joomla API authentication scheme. Instead of having a single token per user we can allow the user to create multiple tokens which can be enabled/disabled, reset, and can also have descriptions, and an expiration time (if desired).
Endpoint
It makes sense to have a separate
/api
application than trying to reuse the main Panopticon application.Do note that we can still access the main Panopticon application's container by instantiating it. This allows us to use the main models in the API.
API features
The features which make sense to have are:
At this stage it does not make sense managing users, tasks, and queues.
The text was updated successfully, but these errors were encountered: