Author: Ahmad SadiaAuthor: Osama ZarraaSupervisor: Francis PalmaSemester: VT 2020Subject: Computer Science

Bachelor Degree Project

Are APIs with Poor Design Subjectto Poor Lexicon?- A Google Perspective

Abstract

REST (Representational state transfer) is an architectural style for distributedhypermedia systems. The simplicity of REST allows straightforward communicationbetween HTTP clients and servers using URIs (Uniform Resource Identifiers) andHTTP methods, e.g., GET, POST, PUT, and DELETE. To do the communicationeffectively between clients and servers, there is a set of best design practices (designand linguistic patterns) shall be followed, and a set of poor design practices (designand linguistic antipatterns) shall be avoided. This study aims to determine whetherthere is a relationship between design and linguistic quality in Google RESTful APIs.To find this relation, a tool is developed to detect patterns and antipatterns in RESTAPIs both in terms of design and linguistic quality. The input of this tool is qualitativedata (Google APIs) and its output is quantitative data. Using this quantitative data, astatistical study is then performed to detect the relation. The tests that are conductedto obtain the final results are Chi-squared and Phi Coefficient tests. The result of Chi-squared that considered all the groups of patterns and antipatterns shows that thereis a statistically significant relation between design and linguistic quality. However,when we assess the individual pair of patterns and antipatterns, our Phi Coefficienttests show that for most of the cases, there is no or negligible relationship betweenlinguistic and design patterns and antipatterns.Keywords: Design patterns, Antipatterns, RESTful APIs, URIs, Uniform ResourceIdentifiers, Detection, Design quality, Google.

PrefaceWe would like to thank our supervisor Dr. Francis Palma who guided us step by step tofinish this thesis project. Without his support and valuable knowledge in this field, wewould not be able to complete this study.

Contents

List of Figures

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 REST APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 REST Design Patterns and Antipatterns . . . . . . . . . . . . . . 21.1.3 REST Linguistics Patterns and Antipatterns . . . . . . . . . . . . 3

1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6 Scope/Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.7 Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Method 82.1 Data Collection and Processing . . . . . . . . . . . . . . . . . . . . . . . 82.2 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Implementation 113.1 Functional Overview of the REST-Ling . . . . . . . . . . . . . . . . . . 113.2 REST Antipatterns Detection . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Express.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.3 Node-fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Linguistic Antipatterns Detection . . . . . . . . . . . . . . . . . . . . . . 133.3.1 SARA Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 Spring boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Results 144.1 Relationship between Design Quality and Linguistic Quality . . . . . . . 144.2 Relationship between Each Pair of Pattern and Antipattern . . . . . . . . 15

4.2.1 Design Antipatterns vs. Linguistic Antipatterns . . . . . . . . . . 154.2.2 Design Antipatterns vs. Linguistic Patterns . . . . . . . . . . . . 174.2.3 Design Patterns vs. Linguistic Patterns . . . . . . . . . . . . . . 184.2.4 Design Patterns vs. Linguistic Antipatterns . . . . . . . . . . . . 18

4.3 Google APIs Detection of Individual Pattern and Antipattern . . . . . . . 194.3.1 Presentation of the Individual Patterns and Antipatterns of Google

APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.2 Presentation of the Total Patterns and Antipatterns of Google APIs 22

5 Analysis 255.1 Design Quality and Linguistic Quality . . . . . . . . . . . . . . . . . . . 255.2 Design Antipatterns and Linguistic Antipatterns . . . . . . . . . . . . . . 255.3 Design Antipatterns and Linguistic Patterns . . . . . . . . . . . . . . . . 25

5.4 Design Patterns and Linguistic Patterns . . . . . . . . . . . . . . . . . . 255.5 Design Patterns and Linguistic Antipatterns . . . . . . . . . . . . . . . . 25

6 Discussion 27

7 Conclusion 297.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

References 30

A Appendix 1 AA.1 Detection Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A.1.1 Design Antipatterns . . . . . . . . . . . . . . . . . . . . . . . . AA.2 Linguistic Antipatterns . . . . . . . . . . . . . . . . . . . . . . . . . . . B

A.2.1 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . DA.3 Phi Coefficient Results . . . . . . . . . . . . . . . . . . . . . . . . . . . E

List of Figures

1.1 Breaking Self-descriptiveness. Source: [1] . . . . . . . . . . . . . . . . . 21.2 Contextless Resource Names. Source: [1] . . . . . . . . . . . . . . . . . 32.1 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1 REST-Ling (the detection tool) . . . . . . . . . . . . . . . . . . . . . . . 124.1 Google Photos APIs Detection of Individual Pattern and Antipattern . . . 204.2 Google Drive APIs Detection of Individual Pattern and Antipattern . . . . 204.3 Google Classroom APIs Detection of Individual Pattern and Antipattern . 204.4 Google Blogger APIs Detection of Individual Pattern and Antipattern . . 214.5 Google Calendar APIs Detection of Individual Pattern and Antipattern . . 214.6 Google Gmail APIs Detection of Individual Pattern and Antipattern . . . 214.7 YouTube APIs Detection of Individual Pattern and Antipattern . . . . . . 224.8 Google Sheets APIs Detection of Individual Pattern and Antipattern . . . 224.9 Google Photos APIs Detection of Total Pattern and Antipattern . . . . . . 224.10 Google Drive APIs Detection of Total Pattern and Antipattern . . . . . . 234.11 Google Classroom APIs Detection of Total Pattern and Antipattern . . . . 234.12 Google Blogger APIs Detection of Total Pattern and Antipattern . . . . . 234.13 Google Calendar APIs Detection of Total Pattern and Antipattern . . . . . 234.14 Google Gmail APIs Detection of Total Pattern and Antipattern . . . . . . 244.15 YouTube APIs Detection of Total Pattern and Antipattern . . . . . . . . . 244.16 Google Sheets APIs Detection of Total Pattern and Antipattern . . . . . . 241.1 Forgetting Hypermedia Detection Algorithm. Source: [1] . . . . . . . . . A1.2 Ignoring Caching Detection Algorithm. Source: [1] . . . . . . . . . . . . A1.3 Ignoring MIME Types Detection Algorithm. Source: [1] . . . . . . . . . B1.4 Ignoring Status Code Detection Algorithm. Source: [1] . . . . . . . . . . B1.5 Misusing Cookies Detection Algorithm. Source: [1] . . . . . . . . . . . . B1.6 Amorphous URIs Detection Algorithm. Source: [1] . . . . . . . . . . . . C1.7 Contextless Resource Names Detection Algorithm. Source: [1] . . . . . . C1.8 Non-hierarchical Nodes Detection Algorithm. Source: [1] . . . . . . . . C1.9 CRUDy URIs Detection Algorithm. Source: [1] . . . . . . . . . . . . . . D1.10 Singularised vs. Pluralised Nodes Detection Algorithm. Source: [1] . . . D1.11 Content Negotiation Detection Algorithm. Source: [1] . . . . . . . . . . D1.12 Entity Linking Detection Algorithm. Source: [1] . . . . . . . . . . . . . E1.13 Response Caching Detection Algorithm. Source: [1] . . . . . . . . . . . E

1 Introduction

Service-Oriented Architecture (SOA) is an architectural choice that has become dominantwithin the industry as it presented new ways of developing, deploying, and consuming asoftware system [2]. There are two major web services standards one can use to buildSOAs and make web applications interoperable: Simple Object Access Protocol (SOAP)and REpresentational State Transfer, known as REST. However, REST has taken the leadand has become a standard architectural style adopted by many software organizations[3].

REST-style is based on the client-server pattern, and REST applications employ fourprimary operations to exchange data; Create, Read, Update, and Delete (CRUD) oper-ations. In the terminologies of REST, they are presented respectively as POST, GET,PUT, DELETE operations. These four operations, along with a single addressing schemebased on a URI (Uniform Resource Identifier), form the architectural structure of REST[4]. REST is simpler and more effective than SOAP in terms of publishing and consum-ing services [5]. Its simplicity allows HTTP clients to communicate with HTTP serversthrough a single URI using its operations [4]. For an application programming interface(API) to be called a REST API, it should conform to the constraints listed by REST [3].

A well-designed REST API can attract client developers to use the service and putthe service provider ahead of the competition. Another important aspect that attractsand benefits developers is the linguistic design quality of the REST API. For example, aURI that can be reused and understood easily helps the client developers while designingand developing their web-based services using that REST API [6]. However, poor designchoices may be introduced while developing the web service, which forces the REST APIto change and could lead to bad design decisions to solve existing problems or challenges(design antipatterns) [7]. These antipatterns may also propagate to include poor linguisticdesign decisions, which might affect the overall RESTfulness of the web service and driveaway potential clients [6].

Nevertheless, there has been no evidence that a poorly designed REST API also hasa poor linguistic quality. Hence, this paper aims to investigate if there is a relationshipbetween REST design quality and linguistic quality in RESTful APIs. For this, we aim toanalyze eight Google APIs.

1.1 Background

Google APIs are designed to communicate between Google servers and client applica-tions. Good design is important for meaningful better communications. To ensure high-quality design, the APIs need to be of high quality both in linguistic aspects and designprinciples of REST. Linguistic design quality ensures that URIs are designed using well-understood identifies that are easy to use and understand by the client developers. More-over, REST design principles suggest a few constraints, e.g., statelessness cache-ability,that must be enforced while designing RESTful APIs. Thus, there might be a potentialrelationship between REST and linguistic design quality.

1.1.1 REST APIs

In the SOA paradigm, web services are servers that are built to support the needs ofeither a site or any other application. In order for the client programs to communicatewith these web services, application programming interfaces (APIs) are used. In otherwords, the main task of an API is to allow computer programs to exchange information

1

between each other. REST is one of the leading architectural styles adopted by manylarge organizations to develop APIs of the various web services they offer; these servicesare also known as REST APIs [8] [9].

1.1.2 REST Design Patterns and Antipatterns

Systems evolve to meet new requirements or add new features. These changes mightaffect the underlying technology and propagate to affect the REST API itself, forcingit to change. All these alterations may reflect negatively on the REST API design, andthis might bring the developer to implement common poor solutions to solve recurringdesign problems (antipatterns). On the other hand, design patterns can be defined as goodsolutions to design problems that might arise while designing and developing a system[7] [10]. In this study, the following design antipatterns are used:

1. Breaking Self-descriptiveness: an antipattern that occurs when REST developersignore the standardized headers, formats, or protocols. It reduces the efficiency,reusability, and adaptability of REST resources [7, 11]. The following figure showsthe detection method of breaking self-descriptiveness antipattern.

Breaking Self-descriptiveness anti-pattern1: proccedure BREAKING-SELF-DESCRIPTIVENESS(request-header, response-header)2: std-request-headers[] ? {"Content-Type", "Proxy-Authorization", "Host", ...} 3: std-response-headers[] ? {"Set-Cookie", "Last-Modified", "Location", ...}4: for each hreq ? request-header.getKeys() and hres ? response-header.getKeys() do5: if (hreq ? std-request-headers[] or (hres ? std-response-headers[]) then6: print "Breaking Self-descriptiveness detected"7: else if 8: end for9: end procedure

Figure 1.1: Breaking Self-descriptiveness. Source: [1]

2. Forgetting Hypermedia: occurs due to the lack of proper entity linking and hin-ders the state transition for REST applications. It restricts the communication be-tween the clients and servers by restricting the client follow links [1, 11].

3. Ignoring Caching: due to this antipattern implementation complexity, many devel-opers, ignore caching capability in both the client and server sides. A developer caneasily break this principle by setting the Cache-Control header to no-cache or no-store, and ignoring an ETag in the response header. Thus, that hinders any caching[1, 11].

4. Ignoring MIME Types: occurs when the server fails to represent resources invarious formats. It may prevent clients, to consume the services more flexibly, andleads to the limitation of the resources reusability and accessibility [1, 11].

5. Ignoring Status Code: this practice affects the semantic communication betweenthe clients and servers negatively; it occurs when REST developers avoid using thedefined set of application-level status code [1, 11].

2

6. Misusing Cookies: an antipattern that concerns the security and privacy of theservice; it occurs when a Set-cookie or a Cookie header contains keys or othertokens that are supposed to be sent by other, more standardized, means [1, 11].

As for the design patterns, the following three are used:

1. Content Negotiation: a design pattern that allows the service to support alternativeresource representations depending on the metadata provided by the consumer. Asa result, service consumption becomes more flexible and highly reusable. If notappropriately applied, this pattern turns into Ignoring MIME Types antipattern [1,9].

2. Entity Linking: if applied, this pattern enables the runtime communication of en-tity relationships by providing links to the service consumers in response messages.If not appropriately applied, this pattern turns into Forgetting Hypermedia antipat-tern [1, 9].

3. Response Caching: a pattern that caches all response messages in the local clientmachine to avoid sending duplicate requests or responses. If not appropriately ap-plied, this turns into Ignoring Caching antipattern [1, 9].

1.1.3 REST Linguistics Patterns and Antipatterns

REST APIs depend a lot on the clear linguistic relationship between the services andtheir resources. However, bad practices, such as poor naming, may reflect negatively onthe REST API design in terms of user usability. Hence, these bad practices are categorizedas antipatterns[6]. In this study, the following linguistic patterns, and their correspondingantipatterns, are used:

1. Contextualised vs. Contextless Resource Names: applying this pattern ensuresthat each URI is contextual. In other words, all nodes in a URI belong to a semanti-cally related context. When not appropriately applied, its corresponding antipatternoccurs and leads to decreased understandability of the service [6]. The follow-ing figure shows the pseudocode of the detection method of Contextless ResourceNames antipattern.

1: procedure CONTEXTLESS-RESOURCE-NAMES(Request-URI) 2: URINodes? EXTRACT-URI-NODES(Request-URI) 3: for each index= 1 to LENGTH(URINodes) 4: Set1? CAPTURE-CONTEXT-BY-SYNSETS(URINodesindex) 5: Set2? CAPTURE-CONTEXT-BY-SYNSETS(URINodesindex+1) 6: if Set1 ? Set2 = ? 7: print "Contextless Resource Names detected" 8: end if 9: end for10: end procedure

Contextless Resource Names

Figure 1.2: Contextless Resource Names. Source: [1]

3

2. Hierarchical vs. Non-hierarchical Nodes: a pattern to ensure that each node in aURI is related, hierarchically, to its adjacent nodes. If not applied, its correspondingNon-hierarchical Nodes occurs, leading to users confusion regarding the purpose ofthe API. Thus, hindering the understandability and the usability of the API [1].

3. Tidy vs. Amorphous URIs: a URI is considered tidy when it has an appropri-ate lower-case resource naming without any extensions, underscores, or trailingslashes. A URI that does not adhere to this pattern is considered an AmorphousURI; this antipattern may mislead users and decrease readability [1].

4. Verbless vs. CRUDy URIs: a verbless URI uses HTTP methods, such as Get,POST, PUT, or DELETE. On the other hand, a CRUDy URI uses terms, such as cre-ate, read, update, or delete; this can confuse the API clients and cause an overloadon the HTTP methods. Moreover, introducing a CRUDy antipattern may triggeranother REST design antipattern, Tunneling Through GET/POST [1].

5. Singularised vs. Pluralised Nodes: singular/plural nouns should be used consis-tently across the API. The last node of a PUT/DELETE request URI should besingular. However, that last node should be plural in POST requests. If this patternis not applied correctly, the Pluralised Nodes antipattern occurs, causing unexpectedserver responses [1].

6. Non-versioned URIs: As web services change, many alterations may occur andpropagate across the service. API versioning is recommended to manage the com-plexity of these changes. URI versioning is one of the most common versioningmethods in REST. A Non-versioned URI antipattern may lead to users’ confusionregarding the API version in use and, in worst scenarios, may break existing con-sumers [12].

1.2 Related Work

This section highlights the effort in [7] and [6] regarding REST design pattern and an-tipatterns, as well as the detection of REST linguistic patterns and antipatterns.

In [7], the authors focus on the REST design patterns and antipatterns. The paperproposes and uses a heuristics-based SODA-R approach (Service Oriented Detection forantipatterns in REST), to detect the poor solutions of design problems, i.e., antipatterns.There are eight REST antipatterns and five REST patterns defined in the article wherethey are used to execute their detection on 12 different well-known REST APIs. As aresult, the approach that was used tends to be accurate, and it detects poor design in theREST APIs, for example, Twitter and Dropbox.

The authors in [6] present 12 linguistic patterns and antipatterns, and proposes theSARA approach (Semantic Analysis of RESTful APIs) that apply both semantic and syn-tactic analysis of REST APIS for the detection of the linguistic patterns and antipatterns.The detection is performed on 18 well-known RESTful APIs, including Facebook andDropbox. The results suggest that most of the APIs follow REST patterns and antipat-terns, especially when it comes to APIs with poor documentation. Furthermore, the detec-tion results confirm the accuracy of the SARA approach compared to the state-of-the-artDOLAR approach (Detection of Linguistic antipatterns in REST) [6].

4

1.3 Problem Formulation

REST APIs have been adopted by many large software organizations for their web ser-vices [6]. Thus, ensuring that a REST API is flexible, reusable, and understandable isessential for API providers to attract more client developers in a competitive market [8];this also means that design quality and linguistic quality are both equally important fac-tors to be considered by REST developers. Previous research has been done on the designand linguistic patterns and antipatterns in REST APIs and the importance of detectingthem [7] [6].

The study, however, aims to investigate the relationship between REST design qualityand linguistic design quality in Google APIs. More specifically, the study aims to investi-gate whether the Google APIs that violate REST design patterns are also subject to poorlinguistic quality, and vice versa.

1.4 Motivation

REST design has a set of best practices (patterns) that is always growing as more researchis conducted on the topic; this set includes design and linguistic patterns that, if fullyadhered to, ensure the RESTfulness of an API. However, if poor practices (antipatterns)are introduced in terms of design quality, what are the chances these antipatterns willpropagate to affect the linguistic design quality or vice versa? The answers to such aquestion might be beneficial to REST developers as it gives them a valuable insight intothe consequential effect of using antipatterns on the RESTfulness of the API.

1.5 Objectives

This section presents the objectives of this study and the research questions that shall beanswered to achieve them.

O1 Investigating the relation between design quality vs. linguistic qualityin Google APIs.

O2 Investigating the relation between design antipattern vs. linguistic an-tipattern in Google APIs.

O3 Investigating the relation between design pattern vs. linguistic patternin Google APIs.

O4 Investigating the relation between design antipattern vs. linguistic pat-tern in Google APIs.

O5 Investigating the relation between design pattern vs. linguistic antipat-tern Google APIs.

O6 Statistically study the relationship between the results obtained in theprevious steps, i.e., see if Google APIs with poor linguistic design qual-ity also significantly violate REST design principles and vice-versa.

Table 1.1: Objectives of the Study

To achieve the above objectives, the following research question and its sub-questions areproposed:

• RQ1: What is the relationship between design quality and linguistic quality inGoogle APIs?

5

RQ1 aims to investigate whether Google APIs that have design antipatterns (orpatterns) are also prone to linguistic antipatterns (or patterns).

• RQ1.1: What is the relationship between design antipatterns and linguistic antipat-terns in Google APIs?

RQ1.1 aims to investigate whether Google APIs that have design antipatterns arealso prone to linguistic antipatterns.

• RQ1.2: What is the relationship between design antipatterns and linguistic patternsin Google APIs?

RQ1.2 aims to investigate whether Google APIs that have design antipatterns arealso prone to linguistic patterns.

• RQ1.3: What is the relationship between design patterns and linguistic patterns inGoogle APIs?

RQ1.3 aims to investigate whether Google APIs that have design patterns are alsoprone to linguistic patterns.

• RQ1.4: What is the relationship between design patterns and linguistic antipatternsin Google APIs?

RQ1.4 aims to investigate whether Google APIs that have design patterns are alsoprone to linguistic antipatterns.

It is expected that the results show a relationship between design and linguistic quality inthe analyzed Google APIs. However, the significance of the correlation might vary wheninvestigating each pair of patterns/antipatterns for the research sub-questions.

1.6 Scope/Limitation

Due to a large number of Google APIs, this research project analyzes only eight GoogleAPIs. Table 1.2 shows the chosen Google APIs to be analyzed against design and linguis-tic patterns and antipatterns. Also, it shows the number of version and instances for eachAPI.

REST APIs Online Documentations Version URIs TestedGoogle Photos APIs developers.google.com/photos v1 17Google Drive APIs developers.google.com/drive v3 42YouTube APIs developers.google.com/youtube v3 52Google Classroom APIs developers.google.com/classroom v1 56Gmail API APIs developers.google.com/gmail/api v1 74Google Calendar API APIs developers.google.com/calendar v3 32Google Sheets APIs developers.google.com/sheets/api v4 17Google Blogger APIs developers.google.com/blogger v3 27

Table 1.2: Google APIs and their Versions and Number of Instances

Moreover, this project detects only the following design and linguistic antipatterns. Table1.3 presents the six design and linguistic antipatterns that are checked against the GoogleAPIs included in this study.

6

Design antipatterns Linguistic antipatternsBreaking Self-descriptiveness Contextless Resource NamesForgetting Hypermedia Non-hierarchical NodesIgnoring Caching Tidy vs. Amorphous URIsIgnoring MIME Types CRUDy URIsIgnoring Status Code Singularised vs. Pluralised NodesMisusing Cookies Non-versioned URIs

Table 1.3: Design antipatterns and Linguistic antipatterns

Finally, the study detects three design patterns and six linguistic patterns, as shown inTable 1.4.

Design Patterns Linguistic PatternsContent Negotiation Tidy URIsEntity Linking Verbless URIResponse Caching Versioned URIs- Contextualised Resource Names- Hierarchical Nodes- Singularised vs. Pluralised Nodes

Table 1.4: Design Patterns and Linguistic Patterns

1.7 Target Group

The study contributes a tool that is developed to detect a set of patterns and antipatterns inRESTful APIs; this tool might be of interest to academics aiming to perform a replicationor do further research on design quality, linguistic quality, or both in the context of RESTAPIs. Practitioners can also use the tool to test the RESTfulness of their APIs at differentstages of development. The findings of the study might reveal useful identifiers that couldhelp developers predict any design or linguistic antipattern proneness.

1.8 Outline

The rest of the paper is structured as follows. Section 2 presents the methodology as wellas the reliability and validity of the study. Furthermore, section 3 explains the implemen-tation of the developed tool to detect the design and linguistic patterns and antipatterns.Then section 4 presents the results of the tool. Moreover, sections 5 and 7 analyze anddiscuss the obtained results, respectively. Finally, section 7 concludes this paper and in-troduce a direction for future work.

7

2 Method

In this section, the methodology followed will be presented. The study is explanatoryand done using both qualitative and quantitative data; it aims at answering the researchquestions listed in Section 1.5.

2.1 Data Collection and Processing

The research conducts a case study on the APIs; it analyzed a total of eight Google APIs(see Table 1.2). The APIs are chosen mainly because of their extensive usage, publicavailability, and the number of instances each API has, which suits the purpose of thisstudy and its time limitation. Qualitative data are first collected manually from the chosenGoogle APIs. A tool is developed to detect the REST and linguistic design patterns andantipatterns. The tool also quantifies the qualitative data collected from the APIs; the datais then analyzed statistically to present evidence whether a correlation between design andlinguistic quality exists or not. The remainder of this section describes the steps followed:

• Step 1: Extracting Google APIS: In this step, the required Google APIs are ex-tracted from https://developers.google.com and stored in a JSON file. Additionally,the required parameters and data-form of each URI are filled into the JSON file.This process is done manually due to the variation between the APIs and URIs.

• Step 2: Implementing the Detection Algorithms: This manual step involved devel-oping a tool to detect patterns and antipatterns of both linguistic- and REST designpractices. The detection algorithms used in the tool are provided in these previ-ous studies [7] and [6]. The development of the tool also made use of the SARA(Semantic Analysis of RESTful APIs) approach followed in this previous research[6] to implement some of the linguistic antipatterns detection algorithms. As fordetecting the design antipatterns, the tool followed the same heuristics-based ap-proach as in this previous research [7]. Finally, the implementation included userinterface implementation.

• Step 3: Detecting Linguistic Patterns and Antipatterns: In this step, the tool au-tomatically aggregates the number and collects the types of linguistic antipatternsdetected in the APIs.

• Step 4: Detecting Design Antipatterns: Similar to step 3, the tool aggregates thenumber of collects the types of design antipatterns detected in the same APIs as instep 3.

• Step 5: Analysing the Data: In this last step, the data obtained from steps 3 and4 are analyzed. The analysis is done by conducting two types of tests, the Chi-Square test of independence1 and the Phi Coefficient test2. The Chi-Square test ofindependence determines if there is a significant relationship between two nominal(categorical) variables [13, 14]. Therefore, this test is used on the two groups ofpatterns/anti-patterns. The Phi coefficient test, on the other hand, is used to deter-mine the relationship strength between two binary (dichotomous) variables [14, 15].Therefore, it is used when assessing individual pairs of patterns/anti-patterns in thisstudy.

1https://rdocumentation.org/packages/stats/versions/3.6.2/topics/chisq.test

2https://rdocumentation.org/packages/psych/versions/1.0-17/topics/phi

8

Step 1 Step 2 Step 3 Step 4 Step 5

Manual step

Automatic step

GoogleAPIs

Extract APIs

Store URIs in JSON file

Detection algorithms

implementation Lingustics patterns andanti-patterns

detectionUser interface implementation

Design patterns and

anti-patterns detection

RESTfulAPIs

Detection Algorithms

Detected patterns & anti-patterns

Statistical Study of the

resultResult

Detected patterns & anti-patterns

Figure 2.1: Research Methodology

Figure 2.1 highlights the steps this research study adapts to achieve the required objec-tives.

2.2 Reliability and Validity

This section discusses the reliability and validity of this study.

2.2.1 Reliability

The method to collect the data from Google APIs sites is done manually in this study.Due to the variation in the HTML structure in Google websites that are used to fetch theneeded APIs, there is no web scraping tool used to scrap the data (URIs). However, thedata are collected and stored in a JSON file manually. In other words, the initial qualitativedata are extracted manually, which introduces the possibility of human errors.

A couple of practices are considered to reduce human errors, such as reduce theamount of data that is entered by copying a base URI for each API. Moreover, presentingthe URIs in the tool in an identical manner to the way they are presented in the cor-responding Google websites contributes to spotting potential errors when validating thequalitative data. Furthermore, the aforementioned data are manually checked by bothstudy authors.

Finally, one more aspect that might affect the reliability of the results is that everyGoogle application detected in the study has multiple versions of API. As an example, thestudy inspects Google Photos APIs; the version being analyzed is version 1. Meanwhile,another API the study inspects, such as Google Drive, uses version 3 as of the date of thisstudy. Therefore, the final results are based on the set of APIs mentioned in table 1.2 andmight differ with different versions of Google APIs.

2.2.2 Validity

In this section, threats to validity are discussed according to the guidelines set by [16].Construct validity ensures that the method followed matches what the study is aiming

to measure. In order to ensure minimum threats to Construct validity, all the rules (de-tection algorithms) are defined and identified according to existing literature and previousresearch on the design and linguistic patterns and antipatterns in RESTful APIs (see [7]and [6]).

9

When it comes to External validity, the study tries to minimize the threats by analyzingonly Google APIs. Due to the limitation of the scope of the study, which only involvesonly Google APIs, the findings cannot be generalized to every existed REST API, but onlyGoogle APIs. Furthermore, the selection of APIs that only belong to Google introducesa selection bias, which adds another threat to the study. However, studying other APIsoutside Google paradigm is beyond the scope of this thesis.

The Internal validity threat present in this paper is the accuracy of the tool that isdeveloped to detect the violations of REST API design pattern principles and poor lin-guistics design. In order to minimize the Internal validity threat, well-known and trustedlibraries are used in the tool to detect REST and linguistic antipatterns, such as StanfordCoreNLP and WordNet. Also, a well tested approaches for design and linguistic detectionsuch as Heuristics-Based, and SARA approaches respectively (see [7] and [6]).

When it comes to Reliability validity, the study is possible to replicate because themethod followed is discussed step by step. Furthermore, the tool developed and the rawdata used to perform the statistical analysis are all available in this paper (see section 3).When it comes to the tool validation in terms of detecting design patterns/antipatterns,the majority of the detected URIs in the APIs have been validated using the providedfeature by Google websites. A user can make a request using a simple form provided foreach URI 3 and gets a response for that request; the validation process is done manuallyby comparing the output of the tool and output of the response fetched in the Googleform. On the other hand, the validation of the linguistic patterns/antipatterns results isdone manually by observing the tool’s findings and the real nodes of each URI.

2.3 Ethical considerations

To construct a REST API or any API, a developer should have many considerations inmind. Users who use a specific API mostly seek to have a reliable application. Therefore,the API application must be well trusted, reliable, and fulfills its purpose; this mostlyrequires a good and well-structured API design and good linguistic quality. Moreover,the API has to be clear from ethical and legal issues when providing an API for publicusage. However, this study does not involve any ethical or legal consideration as thereare no human interactions related to the experiment. The aim of the research is to solelydetect whether there is a relation between design and linguistic qualities in public GoogleAPIs.

3https://developers.google.com/photos/library/reference/rest/v1/albums/addEnrichment

10

3 Implementation

Firstly, the implemented tool checks for design patterns and antipatterns separately, us-ing their algorithms listed in Appendix A, because not every absence of an antipatternautomatically produces a pattern. For example, one of the conditions of the ResponseCaching pattern is that the status-code has to be 304. However, there is no such conditionin its relevant pattern (Ignore caching); refer to 1.2 and 1.13 to see the detailed detectionalgorithms.

Besides, for a URI, there can be cases where one can neither detect a pattern noran antipattern. For example, Forgetting Hypermedia/Entity Linking antipattern/patternalgorithms check only POST and GET methods, and do not check other methods likeDELETE, PUT, and PATCH. Refer to 1.1 and 1.12 to see their detection algorithms.Therefore, some results show that there are undetected cases (left) in the figures of section4.3.2.

On the other hand, when it comes to linguistic patterns/antipatterns detection, thestudy follows the logic that a lack of a linguistic pattern means a linguistic antipatternbecause of the nature of the two. For example, Amorphous URIs vs. Tidy URIs linguisticantipattern/pattern detects whether a URI node contains, i.e. an underscore (_). Therefore,it is possible to conclude that the lack of a Tidy URI pattern in this case automaticallymeant the existence of an Amorphous URI antipattern. Refer to 1.6 to see the detectionalgorithm of Amorphous URIs antipattern.

The rest of this section describes the development process of the tool that is used todetect REST and linguistic antipatterns in Google APIs; it also explains how the toolworks and mentions the approaches, framework, and libraries utilized to implement all ofthe patterns (1.4) and antipatterns (1.3) detection algorithms. The tool can be accessedhere4; use admin as the username and the password.

3.1 Functional Overview of the REST-Ling

REST-Ling is our proposed tool which is a web application that aims to automate thedetection process of Google APIs. The following are some of the tool features:

• Addition of APIs and URIs: REST-Ling allows the user to add one or more URIsmanually, or even through uploading a JSON file. The JSON file can contain mul-tiple APIs with multiple URIs.

• Selection of Patterns and Antipatterns: REST-Ling permits the user to selectthe desired patterns and antipatterns (both of design and linguistic) to be analyzed.Moreover, The analyzing process of the antipatterns is done asynchronously for allthe patterns and antipatterns.

• Customizability: It allows the user to provide the headers and query parametersfor both the whole set of the API and for each URI individually. It also permits theuser to add a path parameter (URI parameter). The user can add them through thesame JSON file where the APIs are attached or directly through the website.

• Generalizability: The detection mechanism is not only restricted to Google APIs.The tool is capable of detecting the design and linguistic patterns and antipatternsof any API, as long as the headers and parameters are set correctly.

4https://rest-ling.com

11

• Security: The tool has an authentication and authorization system, which lets userstest their APIs. It also has an administrative user who has the privileges to create,read, update, and delete users.

• Detail-oriented: The tool provides answers to what, why, and where the designand linguistic antipatterns occur; this allows the user to have a better insight of theAPI quality by checking what type of antipatterns an API has.

• Graphical Representation: The tool provides a graphical representation of thedetection results of the patterns, antipatterns, and unchecked URIs. It providescharts like pie and bar charts.

• Support for Linguistic Analysis: For example, when it comes to detecting Con-textless Resource Names linguistic antipattern, the tool provides functionalities toimport and add acronyms and stop words which are used to create a topic modelused by the SARA approach.

Figure 3.1: REST-Ling (the detection tool)

3.2 REST Antipatterns Detection

This section describes the main software libraries and frameworks that are used in thedevelopment of the tool to detect REST antipatterns.

12

3.2.1 Node.js

Node.js is a JavaScript server-side environment that is built on Chrome’s V8 JavaScriptengine [17]. The major implementation of Node and V8 is in C and C++ where perfor-mance and resources consumption are essential. Node uses an asynchronous I/O eventingmodel to implement the concurrent execution. Whereas, almost all modern environmentsuses multi-threading systems to support concurrency. Node process can be described as asingle-threaded daemon which makes use of V8. [18]. Node.js is the chosen environmentfor the proposed tool due to its flexibility and the large number of packages that NodePackage Manager has.

3.2.2 Express.js

Express.js is a web framework for Node.js that is built on the core Node.js HTTP module.It provides solutions for problems that every developer faces when implementing RESTapplications. Problems like parsing request bodies and cookies, managing sessions, orga-nizing routes, and determining the right response headers based on data types [19].

Express.js is used as the back-end web framework for the proposed tool due to itspopularity in the Node environment [20].

3.2.3 Node-fetch

In order to test the REST design antipatterns of Google APIs, requests from a client-side must be sent. The tool makes use of the Node-fetch package, a part of the NodePackage Manager. Node-fetch is a light-weight module that brings the JavaScript functionwindow.fetch into Node [21].

3.3 Linguistic Antipatterns Detection

The developed tool includes a web service to detect linguistic antipattern. The web appli-cation makes API calls to the web service to check whether a specific URI has a linguisticantipattern or not. This section describes how the web service is developed.

3.3.1 SARA Approach

The approach that is used in this study to detect linguistic antipatterns is the same ap-proach that is followed in this previous [6]. Semantic Analysis of RESTful APIs (SARA)detection approach is eligible to perform improved semantic analysis of RESTful APIs[6]. Additionally, the English dictionaries WordNet5 and Standford’s CoreNLP6 are used.

3.3.2 Spring boot

Spring boot is a java framework that is used to create micro-services and stand-alone andproduction-ready spring application [22]. A Spring Boot application is chosen to be theframework of the web service where the detection of specific linguistic antipatterns isperformed.

5https://wordnet.princeton.edu6https://stanfordnlp.github.io/CoreNLP

13

4 Results

This section shows the results obtained out after running the developed tool. It also showsthe results of Chi-squared test and Phi Coefficient.

4.1 Relationship between Design Quality and Linguistic Quality

The following table is a contingency table of the design antipatterns and the linguisticantipatterns on eight different Google APIs. The aim of extracting these data is to usethem to answer RQ1 What is the relationship between design quality and linguistic qualityin Google APIs?

To answer this question, the following null hypothesis shall be tested.H01: There is no statistically significant relationship between design quality and lin-

guistic quality in Google APIs.We perform the Chi squared test7 to investigate RQ1, thus, accept or reject the null

hypothesis.Moreover, the columns headers of the table represent the linguistic antipatterns and

the rows represent the design antipatterns.

AMO CRD NV CRN NHN SPN TDY VBL VS CZRN HN SPBSD 227 4 0 41 0 64 88 311 315 274 275 42FH 129 1 0 29 0 53 49 177 178 149 154 35

IMT 0 0 0 0 0 0 0 0 0 0 0 0IC 0 0 0 0 0 0 0 0 0 0 0 0

MC 0 0 0 0 0 0 0 0 0 0 0 0ISC 19 0 0 2 0 1 4 23 23 21 23 0EL 37 3 0 3 0 12 16 50 53 50 47 7CN 228 4 0 41 0 65 89 313 317 276 277 42RC 0 0 0 0 0 0 0 0 0 0 0 0

AMO = Amorphous URIs BSD = Breaking Self-descriptiveness TDY = Tidy URIs

CRD = CRUDy URIs FH = Forgetting Hypermedia VBL = Verbless URI

NV = Non-versioned URIs IMT = Ignoring MIME Types VS = Versioned URIs

CRN = Contextless Resource Names IC = Ignoring Caching CZRN = Contextualised Resource Names

NHN = Non-Hierarchical Nodes MC = Misusing Cookies HN = Hierarchical Nodes

SPN = Singularised vs. Pluralised Nodes ISC = Ignoring Status Code SP = Singularised vs. Pluralised Nodes

CN = Content Negotiation EL = Entity Linking RC = Response Caching

Table 4.1: Contingency Table of Design and Linguistic Patterns and Antipatterns

After fetching Table 4.1, a Chi-squared test has been performed. The following tableshows the result of the Chi-squared test of independence between design and linguisticpatterns and antipatterns.

Test Type p-valueχ2(ContingencyTable(DesignPatternAndAntiPatterns, LinguisticPatternsAndAntiPatterns)) < 2.2e-16

Table 4.2: The χ2 Test of Independence between Design and Linguistic Patterns andAntipatterns

7https://www.rdocumentation.org/packages/stats/versions/3.6.2/topics/chisq.test

14

4.2 Relationship between Each Pair of Pattern and Antipattern

This section presents the results of Phi Coefficient test 8when it is performed on the com-binations of design and linguistic patterns and antipatterns.

4.2.1 Design Antipatterns vs. Linguistic Antipatterns

The following table shows the Phi Coefficient test for each Design antipatterns vs. linguis-tic antipatterns. The aim of having this table is to answer RQ1.1 What is the relationshipbetween design antipatterns and linguistic antipatterns in Google APIs?

To answer this question the following null hypothesis shall be tested.H01.1: There is no statistically significant relationship between the design antipatterns

and linguistic antipatterns in Google APIs.

8https://www.rdocumentation.org/packages/psych/versions/1.0-17/topics/phi

15

Pairs of design antipatterns and linguistic antipatterns Phi CoefficientBreaking Self-descriptiveness vs. Amorphous URIs 0.03887Breaking Self-descriptiveness vs. CRUDy URIs 0.00900Breaking Self-descriptiveness vs. Non-version URIs -Breaking Self-descriptiveness vs. Contextless Resource Names 0.03071Breaking Self-descriptiveness vs. Non-hierarchical Nodes -Breaking Self-descriptiveness vs. Singularised/ Pluralised Nodes -0.05821Forgetting Hypermedia vs. Amorphous URIs 0.01379Forgetting Hypermedia vs. CRUDy URIs -0.07097Forgetting Hypermedia vs. Non-version URIs -Forgetting Hypermedia vs. Contextless Resource Names 0.11325Forgetting Hypermedia vs. Non-hierarchical Nodes -Forgetting Hypermedia vs. Singularised/ Pluralised Nodes 0.25984Ignoring MIME Types vs. Amorphous URIs -Ignoring MIME Types vs. CRUDy URIs -Ignoring MIME Types vs. Non-version URIs -Ignoring MIME Types vs. Contextless Resource Names -Ignoring MIME Types vs. Non-hierarchical Nodes -Ignoring MIME Types vs. Singularised/ Pluralised Nodes -Ignoring Caching vs. Amorphous URIs -Ignoring Caching vs. CRUDy URIs -Ignoring Caching vs. Non-version URIs -Ignoring Caching vs. Contextless Resource Names -Ignoring Caching vs. Non-hierarchical Nodes -Ignoring Caching vs. Singularised/ Pluralised Nodes -Misusing Cookies vs. Amorphous URIs -Misusing Cookies vs. CRUDy URIs -Misusing Cookies vs. Non-version URIs -Misusing Cookies vs. Contextless Resource Names -Misusing Cookies vs. Non-hierarchical Nodes -Misusing Cookies vs. Singularised/ Pluralised Nodes -Ignoring Status Code vs. Amorphous URIs 0.06650Ignoring Status Code vs. CRUDy URIs -0.03161Ignoring Status Code vs. Non-version URIs -Ignoring Status Code vs. Contextless Resource Names -0.03532Ignoring Status Code vs. Non-hierarchical Nodes -Ignoring Status Code vs. Singularised / Pluralised Nodes -0.11193

Table 4.3: Relation between Design and Linguistic Antipatterns (Phi Coefficient)

Note that the "-" symbol in table 4.3 means Phi Coefficient is not applicable.

16

4.2.2 Design Antipatterns vs. Linguistic Patterns

The following table shows the Phi Coefficient test for each Design antipatterns vs. lin-guistic patterns. It is meant to answer RQ1.2 What is the relationship between designantipatterns and linguistic patterns in Google APIs?

To answer this question the following null hypothesis shall be tested.H01.2: There is no statistically significant relationship between the design antipatterns

and linguistic patterns.

Pairs of design antipatterns and linguistic patterns Phi CoefficientBreaking Self-descriptiveness vs. Tidy URI (TDY) -0.03887Breaking Self-descriptiveness vs. Verbless URI (VBL) 0.00900Breaking Self-descriptiveness vs. Versioned URIs (VS) -Breaking Self-descriptiveness vs. Contextualised Resource Names -0.03071Breaking Self-descriptiveness vs. Hierarchical Nodes -0.03027Breaking Self-descriptiveness vs. Singularised/ Pluralised Nodes 0.03113Forgetting Hypermedia vs. Tidy URI -0.01379Forgetting Hypermedia vs. Verbless URI 0.07097Forgetting Hypermedia vs. Versioned URIs (VS) -Forgetting Hypermedia vs. Contextualised Resource Names -0.11325Forgetting Hypermedia vs. Hierarchical Nodes -0.02947Forgetting Hypermedia vs. Singularised/ Pluralised Nodes 0.21408Ignoring MIME Types vs. Tidy URI -Ignoring MIME Types vs. Verbless URI -Ignoring MIME Types vs. Versioned URIs (VS) -Ignoring MIME Types vs. Contextualised Resource Names -Ignoring MIME Types vs. Hierarchical Nodes -Ignoring MIME Types vs. Singularised/ Pluralised Nodes -Ignoring Caching vs. Tidy URI -Ignoring Caching vs. Verbless URI -Ignoring Caching vs. Versioned URIs (VS) -Ignoring Caching vs. Contextualised Resource Names -Ignoring Caching vs. Hierarchical Nodes -Ignoring Caching vs. Singularised/ Pluralised Nodes -Misusing Cookies vs. Tidy URI -Misusing Cookies vs. Verbless URI -Misusing Cookies vs. Versioned URIs (VS) -Misusing Cookies vs. Contextualised Resource Names -Misusing Cookies vs. Hierarchical Nodes -Misusing Cookies vs. Singularised vs. Pluralised Nodes -Ignoring Status Code vs. Tidy URI -0.06650Ignoring Status Code vs. Verbless URI 0.03161Ignoring Status Code vs. Versioned URIs (VS) -Ignoring Status Code vs. Contextualised Resource Names 0.03532Ignoring Status Code vs. Hierarchical Nodes 0.10628Ignoring Status Code vs. Singularised vs. Pluralised Nodes -0.10930

Table 4.4: Relation between Design Antipattern and Linguistic Pattern (Phi Coefficient)

Note that the "-" symbol in table 4.4 means Phi Coefficient is not applicable.

17

4.2.3 Design Patterns vs. Linguistic Patterns

The following table shows the Phi Coefficient test for each design patterns vs. linguisticpatterns. The purpose of this table is to answer RQ1.3 What is the relationship betweendesign patterns and linguistic patterns in Google APIs?

To answer this question the following null hypothesis shall be tested.H01.3: There is no statistically significant relationship between the design patterns

and linguistic patterns in Google APIs.

Pairs of design patterns and linguistic patterns Phi CoefficientEntity Linking vs. Tidy URI 0.02106Entity Linking vs. Verbless URI -0.17656Entity Linking vs. Versioned URIs -Entity Linking vs. Contextualised Resource Names 0.09711Entity Linking vs. Hierarchical Nodes 0.01750Entity Linking vs. Singularised/ Pluralised Nodes -0.00055Content Negotiations vs. Tidy URI -Content Negotiation vs. Verbless URI -Content Negotiation vs. Versioned URIs -Content Negotiation vs. Contextualised Resource Names -Content Negotiation vs. Hierarchical Nodes -Content Negotiation vs. Singularised/ Pluralised Nodes -Response Caching vs. Tidy URI -Response Caching vs. Verbless URI -Response Caching vs. Versioned URIs -Response Caching vs. Contextualised Resource Names -Response Caching vs. Hierarchical Nodes -Response Caching vs. Singularised/ Pluralised Nodes -

Table 4.5: Relation between Design Pattern and Linguistic Pattern (Phi Coefficient)

Note that the "-" symbol in table 4.5 means Phi Coefficient is not applicable.

4.2.4 Design Patterns vs. Linguistic Antipatterns

The following table shows the Phi Coefficient test for each design patterns vs. linguisticAntipatterns. The purpose of this table is to answer RQ1.4 Is there a relation betweendesign patterns and linguistic antipatterns in Google APIs?

To answer this question the following null hypothesis shall be tested.H01.4: There is no statistically significant relationship the between the design patterns

and linguistic antipatterns in Google APIs?

18

Pairs of design patterns and linguistic antipatterns Phi CoefficientEntity Linking vs. Amorphous URIs -0.02106Entity Linking vs. CRUDy URIs 0.17656Entity Linking vs. Non-versioned URIs -Entity Linking vs. Contextless Resource Names -0.09711Entity Linking vs. Non-Hierarchical Nodes -Entity Linking vs. Singularised/ Pluralised Nodes 0.02371Content Negotiations vs. Amorphous URIs -Content Negotiation vs. CRUDy URIs -Content Negotiation vs. Non-versioned URIs -Content Negotiation vs. Contextless Resource Names -Content Negotiation vs. Non-Hierarchical Nodes -Content Negotiation vs. Singularised/ Pluralised Nodes -Response Caching vs. Amorphous URIs -Response Caching vs. CRUDy URIs -Response Caching vs. Non-versioned URIs -Response Caching vs. Contextless Resource Names -Response Caching vs. Non-Hierarchical Nodes -Response Caching vs. Singularised/ Pluralised Nodes -

Table 4.6: Relation between Design Pattern and Linguistic Pattern (Phi Coefficient)

Note that the "-" symbol in table 4.6 means Phi Coefficient is not applicable.

4.3 Google APIs Detection of Individual Pattern and Antipattern

This section shows a graphical presentation of the results of the detection of patterns,antipatterns, and not-applicable instances Google API.

4.3.1 Presentation of the Individual Patterns and Antipatterns of Google APIs

This section presents the individual design and linguistic patterns and antipatterns that arefound in the detected Google APIs through a set of bar charts. The patterns are shown ingreen color, antipatterns in red color, and the not-applicable instances in light grey color.Table 4.7 presents the meanings of the antipatterns abbreviations used in the bar charts, italso shows the relevant patterns.

Abbreviation Antipattern PatternBSD Breaking Self-descriptiveness -FH Forgetting Hypermedia Entity LinkingIMT Ignoring MIME Types Content NegotiationIC Ignoring Caching Response CachingMC Misusing Cookies -ISC Ignoring Status Code -AMO Amorphous URIs Tidy URICRD CRUDy URIs Verbless URINV Non-versioned URIs Versioned URIsCRN Contextless Resource Names Contextualised Resource NamesNHN Non-Hierarchical Nodes Hierarchical NodesSPN Singularised vs. Pluralised Nodes Singularised vs. Pluralised Nodes

Table 4.7: Antipatterns Abbreviations

19

The following figures present the detected patterns in green color, antipatterns in red color,and the skipped instances in Google APIs.

Figure 4.1: Google Photos APIs Detection of Individual Pattern and Antipattern

Figure 4.2: Google Drive APIs Detection of Individual Pattern and Antipattern

Figure 4.3: Google Classroom APIs Detection of Individual Pattern and Antipattern

20

Figure 4.4: Google Blogger APIs Detection of Individual Pattern and Antipattern

Figure 4.5: Google Calendar APIs Detection of Individual Pattern and Antipattern

Figure 4.6: Google Gmail APIs Detection of Individual Pattern and Antipattern

21

Figure 4.7: YouTube APIs Detection of Individual Pattern and Antipattern

Figure 4.8: Google Sheets APIs Detection of Individual Pattern and Antipattern

4.3.2 Presentation of the Total Patterns and Antipatterns of Google APIs

Through the following pie charts, this section presents the total design and linguisticpatterns and antipatterns that are found in the detected Google APIs. The patterns arepresented in green color, antipatterns in red color, and the not-applicable (left) instancesin blue color.

Figure 4.9: Google Photos APIs Detection of Total Pattern and Antipattern

22

Figure 4.10: Google Drive APIs Detection of Total Pattern and Antipattern

Figure 4.11: Google Classroom APIs Detection of Total Pattern and Antipattern

Figure 4.12: Google Blogger APIs Detection of Total Pattern and Antipattern

Figure 4.13: Google Calendar APIs Detection of Total Pattern and Antipattern

23

Figure 4.14: Google Gmail APIs Detection of Total Pattern and Antipattern

Figure 4.15: YouTube APIs Detection of Total Pattern and Antipattern

Figure 4.16: Google Sheets APIs Detection of Total Pattern and Antipattern

24

5 Analysis

After performing the detection process of design and linguistic patterns and antipatternson eight different Google APIs, this chapter tries to analyze the results obtained in theprevious section. Also, it presents set of sub-sections to whether accept or reject the nullhypotheses listed in section 1.5.

5.1 Design Quality and Linguistic Quality

In order to examine if there is a relationship between design and linguistic quality, aChi-squared test is performed on all four groups of design and linguistic patterns andantipatterns. The test yielded a statistically significant overall p-value < 0.05. Therefore,the null hypothesis H01 is rejected, and it is concluded that there is a likely relationshipbetween design quality and linguistic quality in Google APIs.

5.2 Design Antipatterns and Linguistic Antipatterns

When studying the relationship between design and linguistic antipatterns, the Phi coeffi-cient method is used. All the results, except one, ranged from -0.19 to +0.19; this meansthere might be a relationship at a negligible level. The interpretation of the Phi coefficientresults is based on this paper [23]. The results lead to failure in rejecting the null hypoth-esis H01.1 due to insufficient statistical evidence. Therefore, it is concluded that there isno relation between design antipatterns and linguistic antipatterns.

5.3 Design Antipatterns and Linguistic Patterns

Similar to H01.1, the Phi coefficient method is used to test H01.2. The yielded resultsexhibits a no or negligible relationship as they ranged from -0.19 to +0.19. One valueshowed a weak positive relationship with a value of 0.21. The results also lead to failurein rejecting the null hypothesis H01.2 due to insufficient statistical evidence. Thus, it isconcluded that there is no relation between design antipatterns and linguistic patterns.

5.4 Design Patterns and Linguistic Patterns

Like the two previous analyses, testing the relationship between design and linguisticpatterns yielded a statistically insignificant Phi coefficient results ranging from -0.19 to+0.19. Thus, a no or negligible relationship between the two measured sets of patterns.The results lead to failure in rejecting the null hypothesis H01.3 due to insufficient sta-tistical evidence. Therefore, it is concluded that there is no relation between design andlinguistics patters.

5.5 Design Patterns and Linguistic Antipatterns

Expectedly, at this point, when the comparison is made between design patterns and lin-guistics antipatterns using the Phi coefficient method, the results exhibits a no or negli-gible relation between the two with result values ranging between -0.19 and +0.19. Theresults lead to failure in rejecting the null hypothesis H01.4 for insufficient statistical evi-dence. Hence, the conclusion is that there is no relationship between design patterns andlinguistic antipatterns.

25

RQ SummaryRQ1 With Chi-squared test performed in a group, there is relation between design

quality and linguistic quality in Google APIs. The statistical evidence issignificant.

RQ1.1 With Phi-coefficient test performed for each pair of design antipattern andlinguistic antipattern, there is no or negligible relation between design an-tipatterns and linguistic antipatterns.

RQ1.2 With Phi-coefficient test performed for each pair of design antipattern andlinguistic pattern, there is no or negligible relation between design antipat-terns and linguistic patterns.

RQ1.3 With Phi-coefficient test performed for each pair of design pattern and lin-guistic pattern, there is no or negligible relation between design and linguis-tics patterns.

RQ1.4 With Phi-coefficient test performed for each pair of design pattern and lin-guistic antipattern, there is no or negligible relation between design patternsand linguistic antipatterns.

Table 5.1: Summary of the Findings

Table 5.1 presents a summary of the answers for the research questions.

26

6 Discussion

This section discusses the study results and the implementation of the tool; then comparesthe findings of this paper with the findings of previous research.

The results show that most analyzed URIs are not CRUDy and are free of Non-Versioned URIs, Contextless Resource Names, and Non-Hierarchical Nodes antipatterns.However, there is a considerable number of Amorphous URIs and Singularised vs. Plu-ralised Nodes antipattern detected. This exhibits that Google APIs are mostly well de-signed in terms of linguistic quality with a chance of slight improvement if we are to saythat they are 100% linguistic antipattern-free.

On the other hand, the detection of the REST design patterns/antipatterns shows that100% of the URIs contain Breaking Self-descriptiveness antipatterns. This is mostly be-cause Google uses some non-standard request or response headers. Moreover, the Forget-ting Hypermedia and Ignoring Status Code antipatterns are present in the majority of theURI. Also, there is an absence of the majority of design patterns except for Content Ne-gotiation, refer to 4.3.1, because Google servers can present resources in various formatsto the clients. This goes to show that when it comes to REST design, Google APIs donot display the same high quality of Linguistic design as the APIs tend to have an almostequal share of patterns and antipatterns. This observation might be affected by the factthat fewer number of design patterns are analyzed in comparison to the linguistic designpatterns. See the figures in the Result section 4 for a better overall overview.

Furthermore, a relation between some of the design antipatterns and linguistic pat-terns is clearly shown by looking at the bar charts listed in section 4.3.1. For example,the noticed relation between Breaking Self-descriptiveness design antipattern (detected inall of the URIs) and Versioned URIs (also detected in all URIs); the relation is presentthroughout all the Google APIs analyzed. This observation matches the finding of theChi-squared test which yields a statistically significant correlation between design andlinguistic patterns/antipatterns.

The implementation of the tool is mainly divided into two parts, the design, and thelinguistic parts. The detection algorithms that are provided in [1] makes the detectionof the design patterns/antipatterns easy to implement. Furthermore, it is noteworthy thatGoogle APIs documentation and the organized presentation of the URIs make it easy tocollect the qualitative data.

On the other hand, in terms of the linguistic antipatterns detection, the tool made useof an old project that article [6] uses to detect the linguistic antipatterns. However, inour tool, we rebuilt this project and integrated it. Having this project helped us to skipimplementing many complicated steps regarding the detection of linguistic antipatterns.

Finally, a previous study (see 1.2) performed design patterns and antipatterns detectionof the same versions of YouTube APIs that our study detects. In contrast to our paper,[7] detects only REST design pattern and anti-patterns. The paper analyzes four morepatterns/antipatterns than our study. However, the number of URIs our study analyzesis much larger than in [7].The similarities of the common antipatterns between the twostudies are that both found that 100% of the URIs have Breaking Self-descriptivenessantipattern and both studies have found zero antipatterns of Ignoring Caching, IgnoringStatus Code, Ignoring MIME Types, and Missing Cookies. On the other hand, somedifferences are found when it comes to Forgetting Hypermedia antipattern, it is hard toestimate the real difference here since [7] found only two antipatterns in three URIs whileour study found 37 antipatterns in 38 URIs. More differences are found between our studyand [7] in all of the three common to REST patterns. our study found that 100% of the

27

URIs have Content Negotiation pattern while [7] found no Content Negotiation pattern.In contrast, when it comes to Entity Linking and Response Caching patterns, our studyfound no patterns. However, [7] found patterns in all of the URIs.

Article [7] was published in 2014. Thus, the time difference between our study and [7]is six years. During this time, many changes may have occurred to the implementation ofYouTube web servers due to the growth of the application. These changes might explainthe few differences between the results of the detection in both studies, but this is anaspect that needs further investigation and deeper analysis.

28

7 Conclusion

Nowadays, REST is the most sought-after architectural choice for building web services.A well-designed REST API that is also easy to understand attracts more REST client de-velopers. Therefore, linguistic and design quality are two equally essential factors everyAPI provider should consider. This empirical study was performed to determine if there isa relationship between design and linguistic quality in RESTful APIs. Using a tool devel-oped especially for this study, eight Google APIs were analyzed, and several design andlinguistic patterns and antipatterns were extracted. Two types of statistical tests were per-formed on the data obtained in order to answer the research questions and sub-questions.The results of the study are summarized as follows:

• A Chi-squared test performed in a group shows there is a statistically significantrelationship between design and linguistic quality in Google APIs (RQ1).

• A Phi-coefficient test performed for each pair of design antipattern and linguisticantipattern shows there is no or negligible relation between design and linguisticantipatterns (RQ1.1).

• A Phi-coefficient test performed for each pair of design antipatterns and linguisticpatterns shows there is no or negligible relation between design antipatterns andlinguistic patterns (RQ1.2).

• A Phi-coefficient test performed for each pair of design patterns and linguistic pat-terns shows there is no or negligible relation between design and linguistic patterns(RQ1.3).

• A Phi-coefficient test performed for each pair of design patterns and linguistic an-tipatterns shows there is no or negligible relation between design patterns and lin-guistic antipatterns (RQ1.4).

7.1 Future work

Further work could involve replicating the study on other Google APIs to combine thedatasets obtained and test the hypotheses again may provide results with better validitywhen performing the Phi coefficient test on each pair of patterns/anti-patterns. Also,expanding the scope of the study to include more popular REST APIs other than Googlemay give a better insight into the emphasis software organizations put on design andlinguistic quality. Finally, the tool developed for this study can be improved to includethe detection of more REST design and linguistic patterns/anti-patterns.

29

References

[1] Sofa, service oriented framework for analysis. Available: http://sofa.uqam.ca [Ac-cessed 28 May 2020].

[2] T. Erl, P. Merson, and R. Stoffers, Service-oriented Architecture: Analysis andDesign for Services and Microservices, ser. Prentice Hall service technology seriesfrom Thomas Erl. Prentice Hall, Service Tech Press, 2016. [Online]. Available:https://books.google.se/books?id=yNmlnQAACAAJ

[3] R. T. Fielding and R. N. Taylor, “Architectural styles and the design of network-based software architectures,” Ph.D. dissertation, 2000, aAI9980887.

[4] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 3rd ed.Addison-Wesley Professional, 2012.

[5] S. Vinoski, “Serendipitous reuse,” IEEE Internet Computing, vol. 12, no. 1, pp. 84–87, 2008.

[6] F. Palma, J. Dubois, N. Moha, and Y. Guéhéneuc, “Semantic analysis of restfulapis for the detection of linguistic patterns and antipatterns,” International Journalof Cooperative Information Systems, vol. 26, no. 20, p. 37, May 2017. AvailableOnline: https://www.worldscientific.com/doi/abs/10.1142/S0218843017420011.

[7] F. Palma, J. Dubois, N. Moha, and Y.-G. Guéhéneuc, “Detection of rest patterns andantipatterns: A heuristics-based approach,” pp. 230–244, 11 2014.

[8] M. Masse, REST API Design Rulebook, ser. Oreilly and Associate Series.O’Reilly Media, 2011. [Online]. Available: https://books.google.se/books?id=4lZcsRwXo6MC

[9] T. Erl, SOA Design Patterns, 1st ed. USA: Prentice Hall PTR, 2009.

[10] W. H. Brown, R. C. Malveau, H. W. McCormick, and T. J. Mowbray, AntiPatterns:Refactoring Software, Architectures, and Projects in Crisis, 1st ed. USA: JohnWiley & Sons, Inc., 1998.

[11] Restful design: Intro, patterns, anti-patterns. Available: https://www.infoq.com/articles/rest-anti-patterns [Accessed 22 May 2020].

[12] B. Varanasi and S. Belida, Spring REST. Apress, 2015. [Online]. Available:https://books.google.se/books?id=2GInCgAAQBAJ

[13] D. Moore, W. Notz, and M. Fligner, The Basic Practice of Statistics. W.H.Freeman and Company, 2013. [Online]. Available: https://books.google.se/books?id=aw61ygAACAAJ

[14] D. J. Sheskin, Handbook of Parametric and Nonparametric Statistical Procedures,4th ed. Chapman & Hall/CRC, 2007.

[15] M. Allen, The SAGE Encyclopedia of Communication Research Methods.SAGE Publications, 2017. [Online]. Available: https://books.google.se/books?id=4GFCDgAAQBAJ

30

[16] R. Yin, Case Study Research and Applications: Design and Methods.SAGE Publications, 2017. [Online]. Available: https://books.google.se/books?id=fHE3DwAAQBAJ

[17] Nodejs, official site. Available: https://nodejs.org/en [Accessed 22 May 2020].

[18] S. Tilkov and S. Vinoski, “Node.js: Using javascript to build high-performance net-work programs,” IEEE Internet Computing, vol. 14, no. 6, pp. 80–83, 2010.

[19] A. Mardan, Express.js Guide: The Comprehensive Book on Express.js. CreatespaceIndependent Pub, 2014. [Online]. Available: https://books.google.se/books?id=5eGRAwAAQBAJ

[20] Express, node introduction. Available: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs/Introduction [Accessed 22 May 2020].

[21] Node-fetch. Available: https://www.npmjs.com/package/node-fetch [Accessed 22May 2020].

[22] Spring boot. Available: https://spring.io/projects/spring-boot#overview [Accessed22 May 2020].

[23] G. Yule, “On the methods of measuring association between two attributes,” Journalof the Royal Statistical Society, vol. 75, no. 6, p. 579, 1912.

31

A Appendix 1

This section consists of two parts. The first part presents the detection algorithms used inthe proposed tool, and the second part shows the results of, in detail, the Phi Coefficienttest.

A.1 Detection Algorithms

This section presents the detection algorithms of design and linguistic antipatterns. More-over, it shows the design patterns algorithms.

A.1.1 Design Antipatterns

This section presents detecting algorithms of design antipatterns used in the tool.

Forgetting Hypermedia anti-pattern

1: ENTITY-LINKING(response-header, response-body, http-method)2: body-links[] ? ETRACT-ENTITY-LINKS(response-body)3: header-link ? response-header.getValue("Link")4: if (http-method = GET and (length(body-links[]) ? 1 or header-link ? NIL)) or5: (http-method = POST and ("Location:" ? response-header.getKeys() or6: length(body-links[]) ? 1))) then7: print "Entity Linking detected"8: end if

Figure 1.1: Forgetting Hypermedia Detection Algorithm. Source: [1]

1: procedure IGNORING-CACHING(request-header, response-header, http-method)2: client-caching ? request-header.getValue("Cache-Control")3: server-caching ? response-header.getValue("Cache-Control")4: if (http-method = GET and ((clinet-caching = "no-cache" or "no-store") or 5: (server-caching = "no-cache" or "no-store") and6: "ETag" ? response-header.getKeys()) then7: print "Ignoring Caching detected"8: end if9: end procedure

Ignoring Caching anti-pattern

Figure 1.2: Ignoring Caching Detection Algorithm. Source: [1]

A

1: procedure IGNORING-MIME-TYPES(request-header, response-header) 2: std-types[] ? {"json", "xml", "yaml", "pdf", "jpeg", ...} 3: client-format[] ? request-header.getValue("Accept") 4: server-format ? response-header.getValue("Content-Type") 5: if server-format[] ? client-format[] and server-format ? std-types[] then 6: print "Ignoring MIME Types detected" 7: end if 8: end procedure

Ignoring MIME Types anti-pattern

Figure 1.3: Ignoring MIME Types Detection Algorithm. Source: [1]

Ignoring Status Code anti-pattern

1: procedure IGNORING-STATUS-CODE(response-body, response-header, http-method) 2: std-codes[] ? {"GET:OK:200", "POST:Created:201", "DELETED:Unauthorized:401", ...} 3: status-description ? EXTRACT-STATUS(response-body) 4: status-code ? EXTRACT-STATUS-CODE(response-header) 5: response-status ? CONCAT(http-method, status-description, status-code) 6: if response-status ? std-codes[] or 7: status-code = NIL then 8: print "Ignoring Status Code detected" 9: end if10: end procedure

Figure 1.4: Ignoring Status Code Detection Algorithm. Source: [1]

1: procedure MISUSING-COOKIES(request-header, response-header) 2: client-cookie ? request-header.getValue("Cookie") 3: server-cookie ? response-header.getValue("Set-Cookie") 4: if (client-cookie ? NIL and CHECK-KEY(client-cookie) = TRUE) or 5: (server-cookie ? NIL and CHECK-KEY(server-cookie) = TRUE) then 6: print "Misusing Cookie detected" 7: end if 8: end procedure

Misusing Cookies anti-pattern

Figure 1.5: Misusing Cookies Detection Algorithm. Source: [1]

A.2 Linguistic Antipatterns

This section presents the detecting algorithms of linguistic antipatterns used in the tool.

B

1: AMORPHOUS-URI(request-URI) 2: URINodes[] ? EXTRACT-URL-NODES(request-URI) 3: for each index = 1 to LENGTH(URINodes) 4: if ((URINodesi.contains("-") or (URINodesi.contains("/") or 5: URINodesi.contains(FIND-FILE-EXTENSTIONS(request-URI)) or 6: URINodesi.contains(FIND-UPPERCASE-RESOURCES(request-URI))) 7: print "Amorphous URI detected" 8: end if

Amorphous URIs

Figure 1.6: Amorphous URIs Detection Algorithm. Source: [1]

1: procedure CONTEXTLESS-RESOURCE-NAMES(Request-URI) 2: URINodes? EXTRACT-URI-NODES(Request-URI) 3: for each index= 1 to LENGTH(URINodes) 4: Set1? CAPTURE-CONTEXT-BY-SYNSETS(URINodesindex) 5: Set2? CAPTURE-CONTEXT-BY-SYNSETS(URINodesindex+1) 6: if Set1 ? Set2 = ? 7: print "Contextless Resource Names detected" 8: end if 9: end for10: end procedure

Contextless Resource Names

Figure 1.7: Contextless Resource Names Detection Algorithm. Source: [1]

1: NON-HIERARCHICAL-NODES(request-URI) 2: URINodes[] ? EXTRACT-URL-NODES(request-URI) 3: for each index = 1 to LENGTH(URI-Nodes) 4: if ((IS-HIERARCHICAL-RELATION(URINodes i, URINodes i+1) = false) or 5: IS-SPECIALSTATION-RELATION(URINodes i, URINodes i+1) then 6: print "Non-hierarchical Nodes detected" 7: end if

Hierarchical vs. Non-hierarchical Nodes

Figure 1.8: Non-hierarchical Nodes Detection Algorithm. Source: [1]

C

1: CRUDY-URI(Request-URI) 2: CRUDyWords[]? {"create", "read", "delete", "destroy", "update", "copy",...} 3: URINodes[] ? EXTRACT-URI-NODES(Request-URI) 4: for each i = 1 to LENGTH (URINodes) 5: if ((SYNONYMS(URINodes i) or ANTONYMS(URINodes i) ? CRUDyWords) 6: print "CRUDy URI detected" 7: end if

Verbless vs. CRUDy URIs

Figure 1.9: CRUDy URIs Detection Algorithm. Source: [1]

Singularised vs. Pluralised Nodes

1: PLURAISED-URI-NODES(request-URI, http-method) 2: lastNode? GET-LAST-NODE(request-URI) 3: secondLastNode ? GET-SECOND-LAST-NODE(request-URI) 4: if (((http-method = PUT or DELETE) and IS-PLURAL-NODE(lastNode) = true) or 5: ((http-method = POST) and (IS-PLURAL-NODE(secondLastNode) = false))) 6: URINodesi.contains(FIND-UPPERCASE-RESOURCES(request-URI))) 7: print "Pluralised URI Nodes detected" 8: end if

Figure 1.10: Singularised vs. Pluralised Nodes Detection Algorithm. Source: [1]

A.2.1 Design Patterns

This section shows, through the following three tables, the detection algorithms used inthe tool to detect the design patters.

1: procedure CONTEXT-NEGOTATION(request-URI, response-header) 2: std-types[]? {"json", "xml", "yaml", "pdf", "jpeg", ...} 3: client-format[] ? request-header.getValue("Accept") 4: server-format ? response-header.getValue("Content-Type") 5: if server-format ? client-format[] and server-format ? std-types[] then

6: print "Content Negotatiation detected" 7: end if 8: end procedure

Content Negotiation Pattern

Figure 1.11: Content Negotiation Detection Algorithm. Source: [1]

D

Entity Linking Pattern

1: procedure ENTITY-Linking(response-header, response-body, http-method) 2: links[]? Extract-Entity-Links(response-body) 3: if (http-method = GET and length(links[] >= 1) or 4: (http-method = POST and ("Location:" ? response-header.getKeys() or 5: length(links[] >= 1))) then 6: print "Entity Linking detected" 7: end if 8: end procedure

Figure 1.12: Entity Linking Detection Algorithm. Source: [1]

1: procedure Response-Caching(request-header, response-header, status-code) 2: client-caching? request-header.getValue("Cache-Control") 3: server-caching? response-header.getValue("Cache-Control") or 4: if (client-caching or server-caching != "no-cach" and "no-store") and 5: ("ETag" ? (request-header.getKeys() or response-header.getKeys())) and 6: status-code = 304 then 8: print "Response Caching detected" 7: end if 9: end procedure

Response Caching Pattern

Figure 1.13: Response Caching Detection Algorithm. Source: [1]

A.3 Phi Coefficient Results

This section presents the results of Phi Coefficient of individual pairs of patterns/anti-patterns in result tables 1.3 and 1.4. The following table explains the four variables (a, b,c, and d) used in the results tables.

Variable 1Found Not Found

Variable 2 Found a bNot Found c d

Table 1.1: A simple contingency table.

Variable 1 in Table 1.1 represents the columns (design patterns and antipatterns in tables1.3 and 1.4 respectively) and variable 2 represents the rows (linguistic patterns and an-tipatterns in tables 1.3 and 1.4 respectively). Furthermore, a stands for the cases found inVariable 1 (design patterns/anti-patterns) and Variable 2 (linguistic patterns/anti-patterns),b stands for the cases found in Variable 2 and not found in Variable 1, c stands for the cases

E

found in Variable 1 and not found in Variable 2, and d stands for the cases not found inboth variables. Furthermore, the abbreviations for patterns and antipatterns used in Table1.3 and 1.4 are explained in Table 1.2 and 4.7 respectively.

Abbreviation PatternEL Entity LinkingCN Content NegotiationRC Response Caching

TDY Tidy URIVBL Verbless URIVS Versioned URIs

CZRN Contextualised Resource NamesHN Hierarchical NodesSP Singularised vs. Pluralised Nodes

Table 1.2: Patterns Abbreviations

BSD FH IMT IC MC ISC

AMOa = 227 b = 88 a = 129 b = 49 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 19 b = 4c = 1 d = 1 c = 99 d = 40 c = 228 d = 89 c = 228 d = 89 c = 228 d = 89 c = 209 d = 85φ = 0.03887 φ = 0.01379 φ = NA φ = NA φ = NA φ = 0.06650

CRDa = 4 b = 311 a = 1 b = 177 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 0 b = 23c = 0 d = 2 c = 3 d = 136 c = 4 d = 313 c = 4 d = 313 c = 4 d = 313 c = 4 d = 290φ = 0.00900 φ = -0.07097 φ = NA φ = NA φ = NA φ = -0.03161

NVa = 0 b = 315 a = 0 b = 178 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 0 b = 23c = 0 d = 2 c = 0 d = 139 c = 0 d = 317 c = 0 d = 317 c = 0 d = 317 c = 0 d = 294

φ = NA φ = NA φ = NA φ = NA φ = NA φ = NA

CRNa = 41 b = 274 a = 29 b = 149 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 2 b = 21c = 0 d = 2 c = 12 d = 127 c = 41 d = 276 c = 41 d = 276 c = 41 d = 276 c = 39 d = 255φ = 0.03071 φ = 0.11325 φ = NA φ = NA φ = NA φ = -0.03532

NHNa = 0 b = 315 a = 0 b = 178 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 0 b = 23c = 0 d = 2 c = 0 d = 139 c = 0 d = 317 c = 0 d = 317 c = 0 d = 317 c = 0 d = 294

φ = NA φ = NA φ = NA φ = NA φ = NA φ = NA

SPNa = 64 b = 251 a = 53 b = 125 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 1 b = 22c = 1 d = 1 c = 12 d = 127 c = 65 d = 252 c = 65 d = 252 c = 65 d = 252 c = 64 d = 230φ = -0.05821 φ = 0.25984 φ = NA φ = NA φ = NA φ = -0.11193

TDYa = 88 b = 227 a = 49 b = 129 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 4 b = 19c = 1 d = 1 c = 40 d = 99 c = 89 d = 228 c = 89 d = 228 c = 89 d = 228 c = 85 d = 209φ = -0.03887 φ = -0.01379 φ = NA φ = NA φ = NA φ = -0.06650

VBLa = 311 b = 4 a = 177 b = 1 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 23 b = 0c = 2 d = 0 c = 136 d = 3 c = 313 d = 4 c = 313 d = 4 c = 313 d = 4 c = 290 d = 4φ = -0.00900 φ = 0.07097 φ = NA φ = NA φ = NA φ = 0.03161

VSa = 315 b = 0 a = 178 b = 0 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 23 b = 0c = 2 d = 0 c = 139 d = 0 c = 317 d = 0 c = 317 d = 0 c = 317 d = 0 c = 294 d = 0

φ = NA φ = NA φ = NA φ = NA φ = NA φ = NA

CZRNa = 274 b = 41 a = 149 b = 29 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 21 b = 2c = 2 d = 0 c = 127 d = 12 c = 276 d = 41 c = 276 d = 41 c = 276 d = 41 c = 255 d = 39φ = -0.030711 φ = -0.11325 φ = NA φ = NA φ = NA φ = 0.03532

HNa = 275 b = 40 a = 154 b = 24 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 23 b = 0c = 2 d = 0 c = 123 d = 16 c = 277 d = 40 c = 277 d = 40 c = 277 d = 40 c = 254 d = 40φ = -0.03027 φ = -0.02947 φ = NA φ = NA φ = NA φ = 0.10628

SPa = 42 b = 273 a = 35 b = 143 a = 0 b = 0 a = 0 b = 0 a = 0 b = 0 a = 0 b = 23c = 0 d = 2 c = 7 d = 132 c = 42 d = 275 c = 42 d = 275 c = 42 d = 275 c = 42 d = 252φ = 0.03113 φ = 0.21408 φ = NA φ = NA φ = NA φ = -0.10930

Table 1.3: Design Antipatterns vs. Linguistic Patterns and Antipatterns

F

EL CN RC

AMOa = 37 b = 16 a = 228 b = 89 a = 0 b = 0c = 191 d = 73 c = 0 d = 0 c = 228 d = 89

φ = -0.02106 φ = NA φ = NA

CRDa = 3 b = 50 a = 4 b = 313 a = 0 b = 0c = 1 d = 263 c = 0 d = 0 c = 4 d = 313

φ = 0.17656 φ = NA φ = NA

NVa = 0 b = 53 a = 0 b = 317 a = 0 b = 0c = 0 d = 264 c = 0 d = 0 c = 0 d = 317

φ = NA φ = NA φ = NA

CRNa = 3 b = 50 a = 41 b = 276 a = 0 b = 0

c = 38 d = 226 c = 0 d = 0 c = 41 d = 276φ = -0.09711 φ = NA φ = NA

NHNa = 0 b = 53 a = 0 b = 317 a = 0 b = 0c = 0 d = 264 c = 0 d = 0 c = 0 d = 317

φ = NA φ = NA φ = NA

SPNa = 12 b = 41 a = 65 b = 252 a = 0 b = 0c = 53 d = 211 c = 0 d = 0 c = 65 d = 252

φ = 0.02371 φ = NA φ = NA

TDYa = 16 b = 37 a = 89 b = 228 a = 0 b = 0c = 73 d = 191 c = 0 d = 0 c = 89 d = 228

φ = 0.02106 φ = NA φ = NA

VBLa = 50 b = 3 a = 313 b = 4 a = 0 b = 0c = 263 d = 1 c = 0 d = 0 c = 313 d = 4

φ = -0.17656 φ = NA φ = NA

VSa = 53 b = 0 a = 317 b = 0 a = 0 b = 0c = 264 d = 0 c = 0 d = 0 c = 317 d = 0

φ = NA φ = NA φ = NA

CZRNa = 50 b = 3 a = 276 b = 41 a = 0 b = 0c = 226 d = 38 c = 0 d = 0 c = 276 d = 41

φ = 0.09711 φ = NA φ = NA

HNa = 47 b = 6 a = 277 b = 40 a = 0 b = 0c = 230 d = 34 c = 0 d = 0 c = 277 d = 40

φ = 0.01750 φ = NA φ = NA

SPa = 7 b = 46 a = 42 b = 275 a = 0 b = 0

c = 35 d = 229 c = 0 d = 0 c = 42 d = 275φ = -0.00055 φ = NA φ = NA

Table 1.4: Design Patterns vs. Linguistic Patterns and Antipatterns

G