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 first aspect that I find interesting and somewhat encouraging is that, in general, people tend to integrate a considerable number of services (4 – 6) and they would integrate more if it were easy. Unfortunately, as we saw when we carried out our own survey on Web APIs documentation, creating clients is hard. The documentation of APIs is often incomplete or even out of date, and one has to proceed through a lengthy and frustrating trial and error process. The work by Apigee and Mashery helps in this respect but one still needs to capture (at least part of) the semantics of these APIs and the resources/data they use, which is not addressed by these systems.
Another aspect highlighted in the survey concerns the maintenance of the APIs integration. Clearly the use of Web APIs does not escape the typical issues encountered in the engineering of systems out of 3rd party distributed components. Hence the need for maintaining the integration code indicated by the survey participants. The figures, though, are not that alarming: 50% of the participants indicated that this requires at most 10% of their time per month. Apparently there will be a second survey that will dig more into this particular issue to confirm that these figures are indeed accurate. Should this be the case, though, I wonder why developers don’t integrate more services, after all the overhead is not so big and the potential advantages are considerable. Is it too risky to depend so much on 3rd parties software? Aren’t there enough APIs per domain that are worth and reliable? Actually, what is the users’ experience with these APIs? Are they reliable? Are they performant? I hope some of these questions will be addressed in the new survey.
One final aspect that I find encouraging from the point of view of the research we are carrying out is that the alignment between data structures was among the main headaches highlighted by the participants. Data integration is a know issue while dealing with distributed systems and this is no exception. Yet, providing semantic descriptions and exposing data in terms of reused vocabularies a la Linked Data could be of help here as well. This is what we are doing in our applications and, although it does not sort out once and for all the data integration problems, it does help.
I take this new survey as another indication that grosso modo we are going in a good direction by supporting people in annotating documentations with SWEET and providing generic machinery that can exploit this for discovery like iServe, or even invocation with OmniVoke. Indeed, one would need well established and adopted standards to sort out the whole set of issues one may encounter but at least we are providing solutions to current problems that can be used right now. Other issues like the eternal discussions on RESTful services vs RPC ones may prove harder to sort out as they tend to be of a rather religious nature. I hope, though, that this “fight” will not prevent Web APIs from evolving and reaching further adoption, standardisation, and support since, after all and despite their drawbacks, Web APIs seem to have overcome the barrier that WSDL-type of Web services didn’t manage to overcome on the Web. And as we saw, this is not due to the use of REST principles as opposed to RPC …