These days, most people speaking APIs think REST API. It's ubiquitous, uses standard protocols and formats, based on giants shoulders...
For the sysadmin REST API like Redfish is a nice way to have a cross-manufacturer out of band management interface e.g.
However in some case, you have constraints that do not allow you to use a REST API. When your system is not reachable directly using the HTTPS protocol e.g. In that case, you can still use an API of course, but based on other standards, such as the venerable STMP one !
Our use case, a training on demand workshop system, involves a Web front-end to manage user registration to run jupyter notebooks hosted on a back-end hosting the jupyterhub instance as well as all the companion systems needed to perform the various workshops proposed (on Redfish, Git, Rust as visible on https://hackshack.hpedev.io/workshops and through the HPE WW demo portal https://hpedemoportal.ext.hpe.com/)
So to make it work flawlessly, we used an SMTP based API, the front-end generating the SMTP content and the back-end using procmail, some scripts and ansible playbooks to manage the setup of the user environment. Once logged on the platform, the user has acces to its own workshop content, with all the links to the other systems available to perform the actions. Why SMTP ? Well our needs were small enough to avoid developing a full REST one (even if we have also one for the front-end), we benefit from the asynchronous aspect of e-mail for free in the management of requests, and it's fun to use old methods to show young engineers that there is more than one way to do it ;-)
Interested ? Well come to hear how we did that and we'll show you how it works, from the automatic deployment of the platform up to the run of a workshop.