Creating added value, innovative applications and services in the web is hindered by the prevailing different formats and models of information retrieved by the various Cloud-based Services (CBS). Additionally, CBS tend to change their Application Programming Interface (API) versions very often, not sufficiently helping the interested enterprises with their adoption as they need to be up-to-date and always functional. The API Builder is a communitybased platform that aims to facilitate developers in adopting a Graph API that unifies the experience of multiple cloud-based services APIs and personal cloudlets, building and maintaining their software applications easily, despite any changes made in the CBS APIs.
These days, more and more users tend to share their data through the World Wide
Web. Social Networks have gathered large silos of information for each of their users
and their interconnections. The Web APIs (Application Programming Interface)
provide all the endpoints needed for a developer to request access into this plethora of
information. All the major social networks like Facebook, Twitter, etc., have an API,
providing most of their core services to third parties for several reasons [
Currently, on the site Programmable Web, which indexes, categorizes and makes
mashups of APIs, 12,987 public APIs are listed and this number is continuously
growing [
Companies, developers and end-users are directly affected by the great changes
that CBS APIs go through continuously. In particular, Facebook API, one of the most
used, is now on version 2.2 and all the client application using version 1.x have until
April 30, 2015 to upgrade to v2.0 or later, as they are going to be deprecated and not
functional afterwards. Other APIs are developed keeping in mind that future versions
will come, ensuring the end-users that what exists now will remain functional, like
Dropbox claims to. Last but not least, many APIs become discontinued, like Desktop
API by Skype. To sum up, APIs are born, evolve and die just like living organisms
and there is need of great effort to keep up with them [
The effects that the Cloud-based Services API changes create on the developer
community have been thoroughly researched [
The structure of the present paper is as follows. Section 2 presents the methodology followed towards the implementation of the OPENi API Builder. In section 3, an overview of the API Builder is given, describing the added value features provided, broken up into 3 smaller sections, the community-based orientation, the documentation in all the standards currently available and lastly the case of CBS API changes handling. In section 4 we provide related work and compare it with the Builder. Section 5 concludes the paper with future work on this matter.
Due to the high complexity of managing and orchestrating the changes in all of the
CBS APIs, a mechanism that would handle these changes had to be implemented. But
first, a research was conducted on the field of API creation. This was completed in 7
stages, based of course on the modeling already conducted for the Graph API [
Step 1. Identifying the needs for handling the Graph API Evolution. In this
step, user stories were created to describe the expected functionalities for future
updates on the Graph API Platform APIs, Objects, methods and CBS.
Step 2. Research of various similar solutions. API creation tools can be found
in many enterprise solutions across the Web, on studies and even as open source
framework for specific code languages. All of these solutions were gathered and
categorized based on the providing features.
Step 3. Connectivity with CBS. The CBSs add extra value to a business
solution as already described. Categorization on the CBS has already taken
place for the Graph API Platform [
The OPENi API Builder is a Web-based platform, implemented as an open source
project, publicly available in Github [
Through its web interface, developers can create, update, delete their own APIs, duplicate existing ones, manage CBS API instances and create correspondences between them. In order to allow for more flexibility, APIs inside Builder consist of multiple components which can also be modified independently. More specifically, they have the following structure: APIs can have multiple Objects and Objects connect with Properties, Methods and CBS.
An authenticated developer can browse public APIs and Objects, vote them up/down, follow them or their creators as shown in Figure 1. API specification and testing is provided through a swagger interface embedded in the website. The provided level of automation in API handling helps developers focus on more meaningful tasks and deliver their work more quickly, increasing business profits.
The innovation of the API Builder can be found in 3 different features, the community backing the API and CBS management along with the social characteristics that are provided, the standards on which the Builder structures its documentation and the Cloud-based Service APIs evolution handling.
The transformation of the World Wide Web these last years, from a static
directory of connected but one-person authored files to the Social Web as we know it
today, usually referenced as Web 2.0, showed the dynamics of the crowd in crafting
truly valuable information. From the Linux Kernel [
The OPENi API Builder has been built to accommodate all the needs of an active community. In Table 1 we can see the actions that are allowed for an authenticated enterprise user. The Builder has a lot of social characteristics as well, allowing the users to interact and engage with each other as well as with their products. The influence indicator of an API for example can be calculated by taking into account the votes and the number of users following that particular API.
Builder User Actions Social Characteristics Parts Create Duplicate View Update Delete Select Publish Propose Vote Up Vote Down Comment/Reply Follow API Y Y Y Y Y Y Y Y Y Y Object Y Y Y Y Y Y Y Y Property Y Y Y Y Method Y
CBS Y Y Y Y Y Y Y Other Users Y Y
In order to avoid duplicate declarations of Objects and promote reusability of objects inside the community, aiming at more sustainable APIs, during the creation of a new object the developer is presented with recommendations of existing ones that could be used instead, based on a combination of approximate string matching on the selected names and similarity computation of the types of objects.
In order to provide a consistent way to document APIs, a number of REST metadata formats has been created. These standards offer a way to represent an API by specifying entry point(s), resource paths, methods to access these resources, parameters to be supplied with these methods, formats of inbound/outbound representations, status codes,error messages and documentary information.
Some of the most popular standards are: Swagger, which offers a large ecosystem
of API tooling, has very large community of active users and great support in almost
every modern programming language and deployment environment. API Blueprints,
where an API description can be used in the apiary platform to create automated
mock servers, validators etc. The Hydra specification [
In order to allow developers to interact with a wider range of APIs independently of their preferred standard, an API can be exposed through the Builder to any of the aforementioned specifications. Moreover, a format transformation component has been implemented, enabling transformation amongst these five specifications.
Details\Specs API Blueprints RAML Hydra WADL Swagger Format Markdown YAML HydrJaSCOoNr-eLDVoc. - XML JSON
75 1819 1.16M
ASL 2.0/TM CC Atrribution 4.0 Sun Microsystems
1.0 Sep 2013 Y 37 N/A 86k 156 N/A 94.1k ASL 2.0
2.0 July 2011 N 732 2459 28M
When a Cloud-based Service decides it is time to change its API, it may deliver additions, deletions and/or alterations on existing Objects and/or the url schema itself. This is a huge overhead for enterprises as specified in the introductory section. It can lead to great increase of the development cost to cover new CBS documentation and code refactoring. The OPENi API Builder provides, to the best of our knowledge, the easiest way to adapt all these changes through the swift reflexes of its community, hence saving time and expenses from enterprises.
All the Objects created at the Builder can have their properties mapped to the corresponding properties of a similar Object of some CBS. These mappings are essentially arrays of labels, where each label represents a property from this particular CBS API. Following version changes is as easy as drag and dropping new labels, removing the deprecated ones and renaming those that need to be altered. Extra attention needs to be given though to the required properties of an Object and the methods that can be applied to each Object. Through a clean user interface, the process of making a match with an API is easier than using wrapper code in some programming language. Even the url that is needed to make the calls can be provided and altered in plain text.
When a new matching version is ready, developers can propose this API for implementation in the official OPENi Platform, and create the documentation in all available specifications. Through the Builder social characteristics, the community advances the most used and up-to-date APIs, promoting them for enterprise solutions.
Several alternative business and developer-oriented solutions exist for creating and managing APIs, based on various or no standards. StrongLoop Arc provides a nice user interface for implementing APIs that are then rendered via a Swagger-based API explorer. Alas, there is no community built upon this solution. Apiary uses API Blueprints code to provide the documentation along with additional features. The downside is that the API management is accomplished via the code. The Apiary solution has a community but no social characteristics. API Designer by Mulesoft has no visual interface as well. The developer writes RAML code to create an API. Appcelerator, a company which targets mobile apps, gives an interface for rapid assembly and hosting of mobile-optimized APIs with some prebuilt connectors. Apigility, an open source tool created by Zend Framework, running on own hosting environment, has visual interface for creating APIs with the ability to produce documentation in Swagger. Apigee Edge API Platform innovates in providing good analytic services for the APIs while providing most of the available CBS connectors. And last but not least, Kimono, by kimonolabs is a very interesting tool which allows users to scrape a website, by simply selecting data on the site. The tool then gathers similar information from the site into an endpoint for a new API. It does not have the same flexibility in managing your API but instead tries to automate the process in existing websites. No API documentation standard is yet provided. All of the feature variations can be found in Table 3 below.
Almost all of these solutions lack the social characteristics that the Builder provides. The most important differences though are the support of multiple available standards for documentation and the mapping between Cloud-based Services and the created APIs that keep track of all the changes in versions.
n o it iifacc e p S Features\Solutions user interface open source community social network
Swagger Hydra RAML
WADL
API Blueprints Datastore Connectors Connectivity with CBS Matching with CBS
In this context, the User Interface is the visual representation of the APIs management board through buttons, textboxes and labels. When no UI is provided, coding is used for APIs administration. The only open source alternative to the API Builder is Apigility. All the other Platforms are products developed by companies and have various pricing plans. Most of them have community features, though in Apiary and Appcelerator it has the form of a team-based product with cooperation features varying according to the pricing plans. Apiary, API Designer and kimono have social features like commenting, following and liking other projects. For Apiary this can be seen only inside the team collaborating on a project. Extra attention has been given to the OPENi API Builder on this matter as already described before in section 4.1.
For the documentation standards supported, StrongLoop Arc and Apigility follow Swagger, while Apiary is based on Api Blueprints and API Designer on RAML. Apigee is among the first ones supporting Swagger. To the best of our knowledge, only the API Builder supports all forms of standards for the documentation. Datastore connectors can be all sorts of SQL and NoSQL databases, like MySQL, MongoDB, SQL Server, etc. StrongLoop Arc and Apigee support integration and retrieval of these databases’ models for creating APIs as well as the API Builder.
Connectivity with CBS is predefined for Appcelerator for a range of enterprise and public data sources like SAP, Oracle, Facebook, Twitter, etc. In the API Builder the Cloud-based Services can be altered dynamically through the community. Last but not least, the feature of matching Objects of APIs to other Objects from CBS can only be met at the API Builder as described before in section 4.3.
OPENi API Builder delivers a unique proposition for enterprises that want to go the extra mile in getting ahead of their competition. Utilizing the power of the community for seamless integration with multiple Cloud-based Services, the API Builder has a great value as a platform for enterprises, start-ups and freelancers. There is no need to keep track of the latest changes in CBS APIs, reassuring continuous uptime in own services. Easy to use and clear, Builder delivers documentation for its APIs in the most popular standards, providing compatibility with most business needs. OPENi API Builder, as a work in progress has to be further expanded and tested to fully discover its potentials and extend it towards the community’s needs. The code is open source, GNU licenced and can be found at Github repository.
As future work we intend to disseminate the power of the Builder and increase its usage among developers/companies. We are also exploring the automated management of Cloud-based Services through different versioning, by parsing a documentation in one of the standards to automatically create the whole API in the Builder. This has already been implemented for Swagger documentation for the needs of interconnection between the Graph API Platform and the API Builder. Since the major documentation standards can be transformed from one to another as described in section 4.2, what remains is to determine the versioning and deprecation policy required to guarantee the most comforting solution for developers, start-ups and enterprises when using the API Builder.
Acknowledgments. This work has been created in the context of the EU-funded project OPENi (Open-Source, Web-Based, Framework for Integrating Applications with Social Media Services and Personal Cloudlets), Contract No: FP7-ICT-317883.