The API Abstraction Layers of CloudRail
In this article you will learn more about the different API abstraction layers of CloudRail including the pros and cons compared to the other layers or manual integrations.
Layer 1: Universal APIs
A Universal API is a complete abstraction across multiple providers. The interface includes a set of functions which work 100% the same for every service which is part of this API. So you can for example use the function upload(), which is part of the Universal Cloud Storage API, exactly in the same way for Dropbox as for Google Drive or OneDrive. This is by far the easiest way to integrate a whole category of services into your application without the need to worry about provider specifics. Compared to native integrations, this is a massive time saver. Nevertheless it is by design always the lowest common denominator, which means, it only includes functions or features which are supported by every single service in the Universal API. Since the service providers usually know what people ask for, these are the most used functions and cover the requirements of 95% of all integration use cases.
Layer 2: Single Integrations
If a feature is not part of a Universal API, check the so called “Single Integrations”. They always represent a service like for example Facebook. This service usually contains a set of functions from one or even multiple Universal APIs, but also has features which are specific for this service and not part of any other Universal API. The usual case is, that you use the simplicity of Universal APIs to cover 95-100% of the features and then add, if required, some provider specific functions via Single Integrations. It basically works exactly like functions out of Universal APIs, but due to the lack of abstraction, you need repeat it for every service. Compared to native integrations, CloudRail still provides you with SDKs, authentication, error handling and most importantly prevents you from API changes.
Layer 3: Advanced Request
This integration layer is for very specific integration requirements which are not covered by Universal APIs or Single Integrations. It basically allows you to define any http API request on your own. So everything you find being documented in the API docs of the respective provider, can also be used via CloudRail. Just go to any Single Integrations and click on “More Functions” to get started. Even though this feels like a bit more complicated, CloudRail still covers some work by handling errors and the authentication. This method gives you the most flexibility but is also the most complicated.
Any questions? Feel free to contact us any time.