Empirical Study on REST APIs usage
in Android Mobile Applications

Mohamed A. Oumaziz, Abdelkarim Belkhir, Tristan Vacher,
Eric Beaudry, Xavier Blanc, Jean-Rémy Falleri and Naouel Moha

Dataset

To construct our dataset, we downloaded Android apps directly from the AndroZoo dataset. You can find the corresponding sha256 of each application of our dataset in this csv file.

Detector source code

Will be released soon.

Survey results

What is your experience with regard to Android application development?

What is your experience with regard to the use of REST services?

In which format should Web Service Libraries (WSL) return the request's result?

If the Web Service Libraries (WSL) returns raw data as String or parser-specific object, which format do you prefer?

Should it be possible for a developer to access the raw HTTP request to the Web Service (e.g., for adding a customized HTTP header) ?

Should Web Service Libraries (WSL) implement the whole service authentication protocol (e.g., complete implementation of OAuth protocol)?

Should Web Service Libraries (WSL) provide Android-dedicated objects (Views, Fragments, ...)?

Should the Web Service Libraries (WSL) support the whole Web service API?

Should the Web Service Libraries (WSL) have its own documentation?

Should the vocabulary used in the Web Service Libraries (WSL) be consistent with the Web service documentation?

In your opinion what other elements do you consider important for Web Service Libraries (WSL)?

It should provide a higher abstraction level than raw requests
Should be kept updated with the web service updates throughout its evolution
as lightweight as possible
Clean data structures
Proper use of HTTP status codes
Secure
custom http transporter (like a OkHTTP client)
Consistency
Test pages / Showcase
Easy setup out of the box via caching, timeouts, retry frequency, error handling, ease of behaviour overriding etc... See okhttp.
- API Design - Performance - Extensibility - Security
Easy of use
Stable, documentation is interactive
RxJava support
fast implementation, less coding
Simplicity
Persistant Identification tools. For example with bearer authentication, a tools to auto manage Token and Refresh Token. And a Wifi auto connect tool : For example i have my own app, and my own store. Login on the app and on the wifi portal page are the same userMail/password When people go to my store with wifi open, i want them to be auto-connected to my wifi. It's actually done on some app, but it's always custom and without standards. Most of the time a big mess. Searching for a login url in xml tag, in an HTML comment on the portail page Filling programatically the from, on the portal page etc ... -_-
Annotation
Simplicity of use and best coverage of the API
Performance, consistent resource definition, consistent pagination