Support

You cannot access Joomla's API application (https://stophersentumoren.nl/api/). You get an error. There's your problem.

The component is actually necessary because of the architecture of Joomla's API application. I recommend reading the API Application section of my book on Joomla! 4 & 5 extensions development.

We need to add additional services to the Joomla! API application to collect Joomla! update information, extension update information (including the Download Key), PHP version information, server information, install updates etc. These services are either not provided by Joomla! itself at all, or are provided in a way that's too limited to be useful for site monitoring.

To extend the Joomla API application you need two things: a plugin in the webservices folder which defines the API endpoint routes, and an API component to handle the endpoints. You cannot have "just" a plugin; it's just not how Joomla! works, and for good reason. I'll get back to that.

However, all Joomla! components MUST have a backend part, and MUST be added to the Components menu. This is hardcoded into Joomla itself. Since we have to have a backend part, instead of putting up a confusing blank page for it I took the liberty of showing the API application's URL and your API application token – information you can obviously find elsewhere in Joomla!.

That is to say, the component was of course not created to show you these redundant pieces of information you could find elsewhere in Joomla!, that would be stupid and I'd like to think that after 18 years of being around I've proven that I am anything but stupid. These redundant pieces of information are shown as a blank page filler in the otherwise meaningless backend part Joomla! requires to have for the component it requires us to build and install (for good reason!) so that the webservices plugin actually does something useful.

But why not just have the webservices plugins handle simple tasks directly? This is something I had discussed with the developer who wrote the API application implementation, many years ago (2018-ish?). Here's the very condensed and not terribly nuanced summary. Most API services are added as part of an existing component. Having the webservices plugin duplicate the code would be contrary to the DRY (Don't Repeat Yourself) principle I had been preaching myself during the initial Joomla! 4 Working Group meetings back in 2015. If you allow components to handle API routes you need to make that mandatory for all API routes for consistency. Having consistency makes the code less error-prone, and troubleshooting much easier. So, yes, having a component provide the actual handling of API routes actually does make sense. It's just annoying when all you need to do is handle API routes.

Side note. WordPress is following the exact opposite approach. Instead of specializing its extension types, it only has one: plugin. A plugin is responsible for registering admin menu entries, handling backend requests for its interface, handle options rendering / storage / retrieval, handle frontend behind-the-scenes stuff (like Joomla! plugins), handle backend and frontend display tasks (like Joomla! modules or components), update provisioning, post-installation tasks, post-update tasks, pre-deactivation tasks, post-uninstallation tasks, scheduled tasks schedule definitions, scheduled tasks definitions, define API routes, handle API routes, define CLI commands, and handle CLI commands among many, many, many other things. This makes the initialisation code of a plugin using more than a small handful of these features or, worse, all of these features –such as Akeeba Backup for WordPress– the stuff of nightmares. It's extremely error-prone and infuriatingly hard to troubleshoot. I think that Joomla follows the right path of extension specialization and having a sane amount of code in each extension type, even if there are some edge cases where this is slightly annoying – like having a backend Components menu entry for a component that really only ever handles API routes.