SDL Studio Public API

I love writing code, something I’ve probably said before in other articles. Writing code means dealing with all sorts of API's all day long, starting from your development platform, in my case Micrososft .Net, to different applications or platform API's. In my humble opinion, in today's world it's all about API's and if I were deciding to buy a piece of software for a company I wouldn't consider any that didn't come with some sort of development experience. I might not need it today but it's definitely going to pay off in the long term. After all, who wants to buy or use a product that doesn't offer flexibility? Based on the type of product, API's can come in multiple forms, for example these days SAAS products tend to offer some sort of REST API which can be consumed in different ways and devices. For the traditional, desktop type products the API is composed from certain classes, events and contracts that allow you to either hook into a particular process or to extend their user interface to some degree. As you probably figured out already, I’m going to talk about the SDL Studio API's in this article but let’s consider specifically that word "Public" … how does it differ from "Private"?

Public vs Private API

The internet is full of debates on this topic trying to figure out pros and cons for this approach. My take on this is that there is no silver bullet solution and the decision should be made based on the specific context of the application/product, how the API is bringing value to the product and the impact on product delivery.

SDL Studio comes with a public API which I will explain in detail in a bit but you might ask yourself why aren't all the application components public? At the end of the day the product is just a bunch of assemblies/dll's that I can easily consume from my code/application. From a strictly technical standpoint this is absolutely correct but other things have to be taken in consideration. Certain parts, that are considered internal, are changing quite often and that means the application/plugin that depends on those components might be broken with every change that’s made, also there are areas that were not necessarily built to be extensible (at least not for the moment). For SDL Studio the benefit of having a clearly defined public API is the guarantee that changes are made in a controlled manner. Of course bugs may still pop-up as in any piece of software but we won't remove or change things overnight just because we need them in a certain way to develop a new feature or fix a bug.

The SDL Studio public API's

At the time I'm writing this article SDL Studio comes with six public API's. We are also at the point to release two new public API's (More details). For a clear understanding of each of the available API's in the following lines I will enumerate them and give some details about each of them together with the corresponding assemblies that you need to include in your application:

Core API

This is the foundation which provides the plug-in framework available in SDL Studio. This is used by other API's to define extension points inside the host application which in this case is SDL Studio. You can use this libraries inside another host application if you are looking for a plugin framework and you want to provide this type feature. Besides the plug-in framework this API provides also the engine besides the settings mechanism you find inside SDL Studio