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 REST API seems to be a step forward towards the direction, that things move on these days.
Words like headless CMSs and Microservices are all over the place for developers.
That said, i am trying to clarify the usefulness of the Joomla REST API, given it's features and shortages.
My purpose is to find out it's usefulness in real case scenarios.
Problem identified
Seems like there are no roles and permissions that can be set for the Joomla resources.
The above lead to the following requirements:
A valid token needs to be used for every request, even if public resources are requested (e.g. public articles).
The token can be generated only for super users.
Any authentication mechanism is missing in the API (e.g. JWT generation).
Open questions
Taking the the above into consideration, seems like the super user's token needs to be exposed in the public, if we intent to consume the API directly from a public app.
Given that this is a big NO, the alternative is to consume the Joomla API internally (e.g. from a node js app).
But this has it's own shortages since, no authentication mechanism exists in the Joomla API, forfeiting one of the most powerful features of the CMS, it's ACL functionality.
I am really interested to know, the usefulness of the API and how the above constraints can be overcome.
The text was updated successfully, but these errors were encountered:
For anyone coming here.
At the moment of writing that, the state of the API seems to be far from beta and many things (including decisions) are pending.
Hence any evaluation is pointless.
Taking the the above into consideration, seems like the super user's token needs to be exposed in the public, if we intent to consume the API directly from a public app.
Well first of all the API endpoints for the application would need to be designed. Any user API should only be revealing the data that it expects to see (for example an app that recieves a category id of 1 for uncategorized because that site doesn't use the category system is pointless).
As a result core can only develop for administration functionality and the idea for the application to interact with itself. So the Authentication has been designed around that. For more information in the approach please read #27021
Given that this is a big NO, the alternative is to consume the Joomla API internally (e.g. from a node js app).
But this has it's own shortages since, no authentication mechanism exists in the Joomla API, forfeiting one of the most powerful features of the CMS, it's ACL functionality.
You would need to build some sort of API Authentication plugin using an appropriate oAuth mechanism.
Alternatively if your content is designed to just outright be public (e.g. blog posts in your app) you can just use the public flag in your webservice plugin.
The REST API seems to be a step forward towards the direction, that things move on these days.
Words like headless CMSs and Microservices are all over the place for developers.
That said, i am trying to clarify the usefulness of the Joomla REST API, given it's features and shortages.
My purpose is to find out it's usefulness in real case scenarios.
Problem identified
Seems like there are no roles and permissions that can be set for the Joomla resources.
The above lead to the following requirements:
Open questions
Taking the the above into consideration, seems like the super user's token needs to be exposed in the public, if we intent to consume the API directly from a public app.
Given that this is a big NO, the alternative is to consume the Joomla API internally (e.g. from a node js app).
But this has it's own shortages since, no authentication mechanism exists in the Joomla API, forfeiting one of the most powerful features of the CMS, it's ACL functionality.
I am really interested to know, the usefulness of the API and how the above constraints can be overcome.
The text was updated successfully, but these errors were encountered: