An explosion of APIs
The Adobe Experience Cloud is an amalgamation of existing tools, which come from various acquisitions. With the advent of the Adobe Experience Platform, new tools have been added to the mix. The consequence is that we have a variety of APIs:
Adobe Analytics Reporting API: 1.4 and 2.0.
Adobe Target: Delivery API and Admin API.
Adobe Audience Manager: REST API.
Adobe Campaign: SOAP API.
Adobe Experience Manager: API Guides.
Adobe Experience Platform: API overview. AEP follows the API-first principle.
All these APIs are more or less RESTful, except for Adobe Campaign, which still uses the horrendous SOAP specification. While this landscape may seem messy, I think it makes sense. If we had a single endpoint for all tools, with different paths to redirect the message to the right destination, the resulting API would be completely unmanageable. Besides, the AEM Assets API could not be more different than an Analytics report request.
That being said, there is one area, where consolidation has its benefits: authentication and authorisation. To understand why we have to remember what we are trying to do with an API: we want to automate what a normal user would do manually through the UI. Therefore, the application or service that interacts with the API, needs to be authenticated and authorised to do the task, exactly the same as a human user.
DashboardAnd here is where Adobe IO comes into play. It is a place where you can create the credentials for machines and grant them access to various tools. Once your code authenticates, it needs to target the solution-specific API to do the actual work. This will become clearer in future posts.