Introduction to Adobe IO

09 Jan 2022 » MSA

I do not think it should come as a surprise to you if I say that I have been a developer in the past. I started my career as a C and C++ developer, with a bit of Java and Perl. Later, I spent 4 years creating websites in PHP, HTML, CSS and JavaScript. As an Adobe consultant, though, I do not have to spend too much time coding. On the other hand, what I can do is use my knowledge of the Adobe stack and my experience as a developer to help developers who need to connect with Adobe tools.

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:

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.

Adobe IO

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.

And 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.

If you click on the previous link, you will notice that Adobe now refers to this website as Adobe Developer, which is the new name of Adobe IO. The reason is that this is meant to be the hub for developers who need to integrate with Adobe tools. Something like One Ring to rule them all. If you take a look at the website, you will see that there are APIs for other tools like Adobe Sign or Adobe Photoshop, reinforcing the goal of the Adobe Developer hub. I will continue using Adobe IO, which I like more and it is in the domain, but remember both terms refer to the same concept.

Finally, I hope you have noticed that the explanation I gave at the beginning of this section is incomplete. Adobe IO goes beyond authentication and authorisation. However, for most of you, this is the only functionality that you will use.

 

This is all for today. I know the post is shorter than usual, but I have just come back from my winter break :smiley:. In the next few posts, I will dive into various topics around Adobe IO.

 

Photo by ThisisEngineering RAEng on Unsplash

Related Posts