their own operations, wrapping theresource information, and then invoke these through one of the HTTP methods2.table 2type of apis Description % occurrence REST 94.9 RPC 5.
05 Table 2 shows the distribution of thedifferent types of APIs. As it can be seen, approximately 95% of the APIs wereobserved to follow REST architecture. A. Input Parameters The information in the API developerguides was thoroughly examined for 181 sub-categorical APIs under 8 selectedAPIs. As it can be seen in Table 3 about 23.
75% of APIs use optional parameterswhich may or may not be Boolean. 33.70% APIs used Boolean as optional inputparameters, 18.23% APIs use query parameters.
76.79% APIs use path parameters,whereas almost 83% APIs use a request body and pass input parameters to thebody. This has a strong effect on the matchmaking and invocation approaches,since one API can be found or not depending on whether optional parameters aretaken into account or not.
Similarly, if invocation is done on the basis ofdefault values, the output results can be drastically changed.table 3input parameters Description Number % occurrence Optional parameters 43 23.75 Path parameters 139 76.79 Query parameters 33 18.
23 Body parameters 149 82.32 Boolean parameters 61 33.70 B. Output Formats In general, JSON and XML are the mostwidely used REST API output formats. The statement was proved through theresult of the performed analysis. As it can be seen in Table 4, there are twomain common output formats – XML and JSON.
XML is provided in 41% of the casesand JSON in 82%, and 27% APIs contain both JSON and XML together, as showed inTable 4. Further output formats include CVS, Text, RSS, Atom, etc. Theseresults show that providing support for the use of XML and JSON addresses thevast majority of the APIs.table 4output formats Description Number % occurrence Only JSON 46 48.93 JSON, other (except XML) 6 6.38 Only XML 7 7.44 XML, other (except JSON) 6 6.38 Only JSON, XML 7 7.
44 JSON, XML, other 19 20.21 Only Atom 0 0 Only SMTP 2 2.12 Total XML 39 41.48 Total JSON 78 82.9 If the output format of the API is designed to be flexible or tosupport the majorly used output formats, the API can be consideredwell-designed. C. Authentication Mechanisms Most of theAPIs require some form of authentication to authorize the users for using datathrough APIs. As it can be seen from Table 5, using OAuth token is by far themost common way of authentication (54%).
It is followed by 50% of APIs, which useAPI key for authentication. table 5authentication mechanisms Description Number % occurrence API Key 27 35.06 API Key, other 12 15.58 OAuth 34 44.155 OAuth, other 8 10.38 App ID, other 3 3.89 Similar to the output format, the form of authentication speaks wellof the API design. D.
SSL Support When settingup an HTTPS connection, client requests a certificate from the server toestablish the server identity. This creates a secure connection, but for theserver needs to qualify the authentic client, hence client certificateauthentication is used. With the use of client authentication, the client sendsits SSL certificate after it verifies the server identity. Then, the client andserver use both certificates to generate a unique key used to sign requestssent between them 14.table 6ssl support Description Number % occurrence APIs that provide SSL support 61 60.
39 APIs that do not provide SSL support 27 26.79 SSL support not mentioned 13 12.87 As it can beseen in Table 6, only 60% of the APIs provide SSL support which is onehindrance towards making the API RESTful or compliant to HTTP protocol. E. Other Documentation Finally, inthis section I present results for API features, which are not strictlynecessary for directly supporting service tasks, but are useful whenimplementing and using the APIs. As Table 7A shows, more than 82% of the APIs requirea request body to make a call to the API. Out of 181 APIs, 63% of them provide samplerequests and responses, which give valuable information to the developers aboutthe structure and the form of the request as well as of the retrieved resultsand, therefore, ease development work.
I also foundthat out of 8 APIs, 75% described the used error codes. Since HTTP provides a setof standard errors, this represents a problem only for custom exceptionimplementations, where developers cannot determine what went wrong and whetherthe error is due to an incorrect invocation, to missing credentials, etc.table 7Acomplementary documentation Description Number % occurrence APIs that require a request body 149 82.32 APIs that provide a sample request/response 115 63.53 APIs that provide an example 36 19.
88 table 7Bcomplementary documentation Description Number % occurrence APIs that provide error or response codes 6 75 II. resultsRQ1: What is the relation betweendistribution of various structural metrics among the selected APIs? Before achieving anysignificant improvement in the RESTfulness of the REST APIs, we need tounderstand a clear picture of its current scenario. The richness of thedescription documents of the API, available information, its developmentprocess, etc. is very essential to contribute in making a REST API morecompliant towards RESTful objective.
Currentrepositories and APIs may face significant challenges in using manual approachto analyze data, which is also maintained manually-it may be prone to errors. Frommy study, it can be clearly stated that majority of APIs follow RESTarchitecture. The description of input parameters is very flexible. JSON andXML are establishing themselves as the main output formats. Even though there isno specific constraint or guidelines for the format of the output, most APIsnowadays give their results either in XML or JSON. Therefore, providing supportfor using and processing only these two formats, would directly contribute tothe overall increase of Web API usability.
Also, providing SSL support to theAPI can make the communication more secure. Building the description documentscontaining examples of request, response, response codes and error codes can beof better help for the developers.It was observedthat APIs within same category, tend to show few similar characteristics, e.g.Most email APIs supported SMTP as output format. Mapping APIs had more numberof mashups than any other categories. Most of the APIs use some form ofauthentication mechanism which is mostly either API key or OAuth. RQ2: What are various designpatterns and anti-patterns of REST API?The increased usage of REST for designing and developing Web-basedapplications confronts common software engineering challenges.
In fact,likewise any software system, RESTful systems must evolve to handle new webentities and resources, i.e., meet new business requirements. Even, the changesin underlying technologies or protocols may force the REST APIs to change. Allthese changes may degrade the design of REST APIs, which may cause theintroduction of common poor solutions to recurring designproblems—antipatterns—in opposition to design patterns, which are goodsolutions to the problems thatsoftware engineers face while designing and developing RESTful systems. Anti-patternsmight be introduced even in the early design phase of RESTful systems.
Antipatterns in RESTful systems not only degrade their design but also maketheir maintenance and evolution difficult, whereas design patterns facilitatethem. A. Design patterns: 1. Content Negotiation: This pattern supportsalternative resource representations, e.g., in json, xml, pdf, etc. so that theservice consuming becomes more flexible with high reusability. Servers canprovide resources in any standard format requested by the clients.
2. End-point Redirection: The redirection featureredirects clients to a new location to follow with one of the status code among301, 302, 307, or 308, for old-deprecated APIs.3. Entity Linking: This pattern enables runtimecommunication via links provided by the server in the response body or viaLocation: in the response header, to let clients find related entries atruntime.4.
Entity Endpoint: It is a facility of providingmultiple endpoints where each entity or a resource is uniquely identified.5. Response Caching: Response caching is a goodpractice to avoid sending duplicate requests and responses by caching allresponse messages in the local client machine.6. Uniform Contract: Based on three fundamentalelements: resource identifier, methods and media types.
7. Idempotent capability: It focuses on how can aservice capability safely accept multiple copies of the same message to handlecommunication failure. B.