4,694 research outputs found
A First Look at the Deprecation of RESTful APIs: An Empirical Study
REpresentational State Transfer (REST) is considered as one standard software
architectural style to build web APIs that can integrate software systems over
the internet. However, while connecting systems, RESTful APIs might also break
the dependent applications that rely on their services when they introduce
breaking changes, e.g., an older version of the API is no longer supported. To
warn developers promptly and thus prevent critical impact on downstream
applications, a deprecated-removed model should be followed, and
deprecation-related information such as alternative approaches should also be
listed. While API deprecation analysis as a theme is not new, most existing
work focuses on non-web APIs, such as the ones provided by Java and Android. To
investigate RESTful API deprecation, we propose a framework called RADA
(RESTful API Deprecation Analyzer). RADA is capable of automatically
identifying deprecated API elements and analyzing impacted operations from an
OpenAPI specification, a machine-readable profile for describing RESTful web
service. We apply RADA on 2,224 OpenAPI specifications of 1,368 RESTful APIs
collected from APIs.guru, the largest directory of OpenAPI specifications.
Based on the data mined by RADA, we perform an empirical study to investigate
how the deprecated-removed protocol is followed in RESTful APIs and
characterize practices in RESTful API deprecation. The results of our study
reveal several severe deprecation-related problems in existing RESTful APIs.
Our implementation of RADA and detailed empirical results are publicly
available for future intelligent tools that could automatically identify and
migrate usage of deprecated RESTful API operations in client code
Classification of changes in API evolution
Applications typically communicate with each other, accessing and exposing data and features by using Application Programming Interfaces (APIs). Even though API consumers expect APIs to be steady and well established, APIs are prone to continuous changes, experiencing different evolutive phases through their lifecycle. These changes are of different types, caused by different needs and are affecting consumers in different ways. In this paper, we identify and classify the changes that often happen to APIs, and investigate how all these changes are reflected in the documentation, release notes, issue tracker and API usage logs. The analysis of each step of a change, from its implementation to the impact that it has on API consumers, will help us to have a bigger picture of API evolution. Thus, we review the current state of the art in API evolution and, as a result, we define a classification framework considering both the changes that may occur to APIs and the reasons behind them. In addition, we exemplify the framework using a software platform offering a Web API, called District Health Information System (DHIS2), used collaboratively by several departments of World Health Organization (WHO).Peer ReviewedPostprint (author's final draft
Why Do Developers Get Password Storage Wrong? A Qualitative Usability Study
Passwords are still a mainstay of various security systems, as well as the
cause of many usability issues. For end-users, many of these issues have been
studied extensively, highlighting problems and informing design decisions for
better policies and motivating research into alternatives. However, end-users
are not the only ones who have usability problems with passwords! Developers
who are tasked with writing the code by which passwords are stored must do so
securely. Yet history has shown that this complex task often fails due to human
error with catastrophic results. While an end-user who selects a bad password
can have dire consequences, the consequences of a developer who forgets to hash
and salt a password database can lead to far larger problems. In this paper we
present a first qualitative usability study with 20 computer science students
to discover how developers deal with password storage and to inform research
into aiding developers in the creation of secure password systems
Repairing Deep Neural Networks: Fix Patterns and Challenges
Significant interest in applying Deep Neural Network (DNN) has fueled the
need to support engineering of software that uses DNNs. Repairing software that
uses DNNs is one such unmistakable SE need where automated tools could be
beneficial; however, we do not fully understand challenges to repairing and
patterns that are utilized when manually repairing DNNs. What challenges should
automated repair tools address? What are the repair patterns whose automation
could help developers? Which repair patterns should be assigned a higher
priority for building automated bug repair tools? This work presents a
comprehensive study of bug fix patterns to address these questions. We have
studied 415 repairs from Stack overflow and 555 repairs from Github for five
popular deep learning libraries Caffe, Keras, Tensorflow, Theano, and Torch to
understand challenges in repairs and bug repair patterns. Our key findings
reveal that DNN bug fix patterns are distinctive compared to traditional bug
fix patterns; the most common bug fix patterns are fixing data dimension and
neural network connectivity; DNN bug fixes have the potential to introduce
adversarial vulnerabilities; DNN bug fixes frequently introduce new bugs; and
DNN bug localization, reuse of trained model, and coping with frequent releases
are major challenges faced by developers when fixing bugs. We also contribute a
benchmark of 667 DNN (bug, repair) instances
A Quantitative Study of Java Software Buildability
Researchers, students and practitioners often encounter a situation when the
build process of a third-party software system fails. In this paper, we aim to
confirm this observation present mainly as anecdotal evidence so far. Using a
virtual environment simulating a programmer's one, we try to fully
automatically build target archives from the source code of over 7,200 open
source Java projects. We found that more than 38% of builds ended in failure.
Build log analysis reveals the largest portion of errors are
dependency-related. We also conduct an association study of factors affecting
build success
Web API Fragility: How Robust is Your Web API Client
Web APIs provide a systematic and extensible approach for
application-to-application interaction. A large number of mobile applications
makes use of web APIs to integrate services into apps. Each Web API's evolution
pace is determined by their respective developer and mobile application
developers are forced to accompany the API providers in their software
evolution tasks. In this paper we investigate whether mobile application
developers understand and how they deal with the added distress of web APIs
evolving. In particular, we studied how robust 48 high profile mobile
applications are when dealing with mutated web API responses. Additionally, we
interviewed three mobile application developers to better understand their
choices and trade-offs regarding web API integration.Comment: Technical repor
Policy Enforcement with Proactive Libraries
Software libraries implement APIs that deliver reusable functionalities. To
correctly use these functionalities, software applications must satisfy certain
correctness policies, for instance policies about the order some API methods
can be invoked and about the values that can be used for the parameters. If
these policies are violated, applications may produce misbehaviors and failures
at runtime. Although this problem is general, applications that incorrectly use
API methods are more frequent in certain contexts. For instance, Android
provides a rich and rapidly evolving set of APIs that might be used incorrectly
by app developers who often implement and publish faulty apps in the
marketplaces. To mitigate this problem, we introduce the novel notion of
proactive library, which augments classic libraries with the capability of
proactively detecting and healing misuses at run- time. Proactive libraries
blend libraries with multiple proactive modules that collect data, check the
correctness policies of the libraries, and heal executions as soon as the
violation of a correctness policy is detected. The proactive modules can be
activated or deactivated at runtime by the users and can be implemented without
requiring any change to the original library and any knowledge about the
applications that may use the library. We evaluated proactive libraries in the
context of the Android ecosystem. Results show that proactive libraries can
automati- cally overcome several problems related to bad resource usage at the
cost of a small overhead.Comment: O. Riganelli, D. Micucci and L. Mariani, "Policy Enforcement with
Proactive Libraries" 2017 IEEE/ACM 12th International Symposium on Software
Engineering for Adaptive and Self-Managing Systems (SEAMS), Buenos Aires,
Argentina, 2017, pp. 182-19
Why and How Java Developers Break APIs
Modern software development depends on APIs to reuse code and increase
productivity. As most software systems, these libraries and frameworks also
evolve, which may break existing clients. However, the main reasons to
introduce breaking changes in APIs are unclear. Therefore, in this paper, we
report the results of an almost 4-month long field study with the developers of
400 popular Java libraries and frameworks. We configured an infrastructure to
observe all changes in these libraries and to detect breaking changes shortly
after their introduction in the code. After identifying breaking changes, we
asked the developers to explain the reasons behind their decision to change the
APIs. During the study, we identified 59 breaking changes, confirmed by the
developers of 19 projects. By analyzing the developers' answers, we report that
breaking changes are mostly motivated by the need to implement new features, by
the desire to make the APIs simpler and with fewer elements, and to improve
maintainability. We conclude by providing suggestions to language designers,
tool builders, software engineering researchers and API developers.Comment: Accepted at International Conference on Software Analysis, Evolution
and Reengineering, SANER 2018; 11 page
- …