Although this is somewhat old news, I still would like to drop a few lines about this work for it still can yield further fruits. We have been working for some time now on better supporting the use of Web APIs. So far, we have analysed the current state of affairs and have provided a set of technologies including conceptual models and tools for supporting the life-cycle of Web APIs and applications based on those. We worked in the past on a tool and conceptual model for creating semantic annotations for Web APIs with SWEET, advanced discovery support for APIs annotated in this manner through iServe, as well as for supporting the invocation of any of those APIs through a single generic invocation engine called OmniVoke.
Although the solutions we devised do provide a considerable improvement in the level of automation that one can benefit from while building applications based on Web APIs, it is all predicated on the existence of these semantic annotations and there are not many available. Indeed, better user assistance but also the availability of good incentives play an increasingly important role and we are devoting efforts to these aspects. I’d like, however, to talk in this post about another path we have been working on lately which takes as starting point Web APIs as they currently are. We have presented this work both at the AAAI Symposium – Intelligent Web Services Meet Social Computing and at ISWC.
We are currently offering a fully-funded studentship commencing January 2013. Applications are invited from UK, EU and international students for full-time, 3-year study on the following PhD project:
As the role of the Web has become central within ICT and our society in general, it is increasingly apparent that although services are widely used, current practices are largely driven by less traditional factors than those initially anticipated and prescribed by software engineering methodologies. In this PhD Studentship we would like to carry out research on services from a fundamentally different perspective from the one commonly adopted in Computer Science. Notably, rather than focusing on defining new theoretical principles and frameworks for supporting the development of service-oriented systems, we would like to exploit the plethora of information that exists on the Web to figure out what current practices are, gain a better understanding on how service providers and service consumers are behaving, and use this knowledge to better support their practices. By doing so we expect to gather a richer understanding on current development processes in the Web era, so that we can determine the main factors driving services successes and failures, produce models that could predict the popularity or determine the simplicity of usage of a given service, etc. It is only then that we will be able to devise adequate technologies for supporting service providers and consumers, as well as identify and propose means for bridging the gap between current practices and best principles that could lead us towards a more sustainable future.
Deadline for applications: 16th November 2012.
Further information: http://kmi.open.ac.uk/studentships/mining-services-on-the-web.php
After quite some time without posting, I’d like to retake it and break momentarily the series on USDL (on which both Torsten Leidig from SAP and I have continued working) to quickly post an interesting survey on Web APIs I just found out about. The survey comes from the Trove blog and it was aimed at quantifying the actual costs regarding Web APIs integration. The survey corroborates some of the issues we found out in our own survey, e.g., the poor quality of the documentation, but it also highlights some other interesting aspects.
The world of services on the Web has traditionally been limited to “classical” Web services based on WSDL and SOAP. For quite some time now, though, services on the Web are increasingly marked by the domination of Web APIs, which includes, but is not limited to, RESTful services. Despite their popularity currently the development of Web APIs is not guided by standards, patterns, or guidelines. It is more an art than a science whereby Web APIs are more often than not solely described in HTML as part of a webpage rather than using an interface description language that could better support software development.
Lately, there is significant effort devoted to this “new kind” of services. A good deal of this work has focused on better understanding the architectural implications of the REST Representational State Transfer (REST) principles  as opposed to traditional Web services , or to better supporting their composition and invocation [3,4]. Most of this work, however, takes REST principles as a starting point despite the fact that on the Web many of the existing APIs do not strictly adhere to these constraints. Before we can make any significant improvement to current practices and technologies, it is thus necessary to reach a deeper understanding of existing Web APIs regarding for instance how they are actually described, what principles they follow and what drives their reuse. It is only in the light of these findings that we may then try and figure out how existing solutions, as opposed to ideal scenarios, could be enhanced and better supported. To this end we recently carried out a thorough analysis of large body of Web APIs . This exercise has revealed interesting issues which I’d like to briefly highlight herein.