By Iosif Alvertis, Michael Petychakis, & Fenareti Lampathaki (NTUA)
It’s been a while since our last post about the API analysis, but it was a quite busy period for us to implement and test what has been designed during the first year of the project. During the last months, we have ended with a concrete definition about what a Graph API is; during our analysis on APIs Cloud Based Services and our study on existing research, no clear definition was available. Thus, combining existing research, empirical research and services modeling, we ended up with the following definition:
“A Graph API is a RESTful, user-centric, hypermedia API that organizes web resources under a unified meta-model of Objects, Aggregations of objects and Connections towards them which are created by users. It is based on a common dictionary and it includes a minimum set of properties in order to reduce time and cost of connection and integration with other APIs.”
In other words, when browsing an object, it should be clear for the developer how he should navigate through connections, through the response of the API itself, following the basic rules of how Objects, Aggregations and Connections are related.
Within the final definition and specification of the Graph API, the analysis of the Cloud Based Services (CBS) continued with a detailed, updated specification of the Generic APIs incorporating feedback from the OPENi platform implementation. In principle, the Generic APIs are categories of objects that provide similar objects and combine objects from related Cloud Based services. So far, the recognized categories are: Profiles API, Activity API, Location API, Media API, Products & Services API and Communication API. In the following figure, the CBS APIs are grouped based on how they have been mapped to objects of our Generic APIs (although there are cases in which a CBS API like Facebook spans more than 1 Generic API and in which more services and protocols have been studied, like Amazon and eBay modeling for the Product & Services API, or the XMPP protocol in order to model the Communication API, yet they have been excluded from the mapping due to the limitations put from such API methods and the need to give an object-based, RESTful API).
In this direction, the Generic APIs were integrated in the broader architecture of the project. In the figure below, it is visible how each Generic API is related with the Cloudlet API, the Context API (i.e. giving additional metadata on Graph API objects), and the Service Enablers that provide advanced logic to the OPENi platform. All these APIs together compose the OPENi API Framework, which can be described as:
“OPENi API Framework is the whole set of different APIs used by third party developers to build their applications over an OPENi platform.”
It’s definitely a long way towards an interoperable and clean design of modern services, even if REST as a protocol has significantly contributed in that direction. It is mainly a matter of proper design, agreed and followed by the community, to keep such services transparent and reusable. For that reason, we are planning to make available the detailed modeling performed on our Generic APIs, through the OPENi platform during the next months, in order to gather feedback and allow the community to validate, extend and reuse our work.
Finally, the Graph API is implemented in the integrated OPENi platform through the OPENi API component, which is addressed to developers and applications and constitutes the central point of reference for the OPENi API Framework at design time and runtime. The OPENi API Platform serves a two-fold purpose:
- To ensure that developers have access to the API documentation in which they are interested and may extend it according to their needs.
- To handle all requests from OPENi-enabled applications that utilize the OPENi API Framework.
Relative blog posts will follow, with instructions how to use the OPENi API platform and some demo applications.
More details are also available in our deliverables and, in particular, in OPENi APIs Specification – Phase 2 (D3.4) that will be soon publicly available! In the meantime, you may have a look at the draft OPENi APIs Specification – Phase 1 (D3.1).
Note: We are excited to announce that our work and research on a Graph API has been accepted in: (a) AICCSA’ 2014 and will be presented on November 10-13, 2014, in Doha, Qatar, under the title ““A Community-based, Graph API Framework to Integrate and Orchestrate Cloud-Based Services”, and (b) PROVE-2014 and will be presented on October 6-8, 2014, in Amsterdam, under the title “Enterprise Collaboration Framework for Managing, Advancing and Unifying the Functionality of Multiple Cloud-based Services with the Help of a Graph API”.