Recent developments in the world of services on the Web show that both the number of available Web APIs as well as the applications built on top is constantly increasing. This trend is commonly attributed to the wide adoption of the REST architectural principles. Still, the development of Web APIs is rather autonomous and it is up to the providers to decide how to implement, expose and describe the Web APIs. The individual implementations are then commonly documented in textual form as part of a webpage, showing a wide variety in terms of content, structure and level of detail. As a result, client application developers are forced to manually process and interpret the documentation. Before we can achieve a higher level of automation and can make any significant improvement to current practices and technologies, we need to reach a deeper understanding of their similarities and differences. Therefore, in this paper we present a thorough analysis of the most popular Web APIs through the examination of their documentation. We provide conclusions about common description forms, output types, usage of API parameters, invocation support, level of reusability, API granularity and authentication details. The collected data builds a solid foundation for identifying deficiencies and can be used as a basis for devising common standards and guidelines for Web API development.
The first study on the state of Web APIs was presented by @cite_0 and features a comprehensive overview through the analysis of 222 Web APIs in 2010. While aim to draw conclusions on the state of the entire world of APIs on the Web, we focus on the most popular and common ones, substituting a larger dataset for more and other types of features. Another more recent study from 2012 was provided by @cite_6 , wherein the authors analyze a dataset of twenty Web APIs by a broad range of features, some of which were incorporated in our survey. Similar to our study, the dataset was gained by selecting top ranked entries from the ProgrammableWeb directory, using the number of mashups as the sorting criteria. The rather limited dataset and fast moving developments in the world of services on the web necessitate taking another look at the current state of Web APIs. Other older studies, devoted to investigating Web Services exist. The authors in @cite_3 provide a study on Web services but their data is restricted to only a few characteristics and a single source.
@cite_0 @cite_3 @cite_6
2141233033 38513179
Web services technology has received much attention in the last few years, and a lot of research efforts have been devoted to utilizing services on the Internet to fulfill consumers' requirements. However, little research has been done on the current status of web services on the Internet, which has a great impact on current research. Enlightened by this situation, we made an exploratory study of the current status of web services on the Internet. Our study mainly focused on the investigation of four aspects, including the number, complexity, quality of description and the function diversity of available web services on the Internet. A web services investigation system is built up to harvest web services from the Internet and calculate the statistical results. The investigation results are reported in this paper, and, based on our study, the development trend of web services technology is also discussed in this paper. Since Fielding's seminal contribution on the REST architecture style in 2000, the so-called class of RESTful services has taken off to challenge previously existing Web services. Several books have since then emerged, providing a set of valuable guidelines and design principles for the development of truly RESTful services. However, today's most popular "RESTful" services adopt only few of these guidelines, resulting in overburdening developers integrating multiple services in mashup applications. In this paper we present an in-depth analysis for the top 20 RESTful services listed on programmableweb.com against 17 RESTful service design criteria found in literature. Results provide evidence that hardly any of the services claiming to be RESTful is truly RESTful, probably due to the lack of rigidness and ease-of-use of currently available decision criteria. To improve the situation, we provide recommendations for various stakeholder groups.