REST APIs, as well as their deficits with respect to compliance with the REST architectural style Knowing and analyzing this data in detail, may help to improve the state of the art with purposeful solutions. Software systems may face recurring design problems good solutions to which are known as design patterns that improve the design quality and facilitate maintenance and evolution of software systems. Anti-patterns are the attempted RESTful HTTP usage that creates issues showing the failed adoption of REST ideas. Sometimes it is a poor and counterproductive solution to the design issues. Therefore it is necessary to detect REST anti-patterns for improved maintenance and evolution of RESTful systems. RESTful services are gaining increasing popularity day by day Twitter, Google, Facebook, YouTube, and many more companies leverage REST. However, the usage of REST for designing and developing Web-based applications has increased which has raised the threats to common software engineering challenges. In fact like any other software system, RESTful systems also must evolve to handle new resources i.e meet new business requirements and become scalable. Even the changes in underlying technologies or protocols may force the REST APIs to change.
We Can Write an Original Essay Just for You.
Any subject. Any type of essay. We’ll even meet a 3-hour deadline.
All these changes may degrade the design of REST APIs which may cause the introduction of common poor solutions to recurring design problems, anti-patterns in opposition to design patterns which are good solutions to the problems that software engineers face while designing and developing. RESTful systems. Anti-patterns might be introduced in the early design phase of RESTful systems. Anti-patterns in RESTful systems not only degrade their design but also make their maintenance and evolution difficult whereas design patterns facilitate them 11, 13, 15. It is important to detect and learn about the Anti patterns because it may strictly violate one of the REST principles. Uniform interface. Client-server separation Stateless Cacheable and Layered Anti patterns might also hinder the understandability for clients to reduce scalability and reusability cause security issues or cause misapplication of HTTPS methods. The aim of this paper is to answer three defined Research Questions using the structural analysis of APIs and their design patterns anti-patterns RQ1. What is the relation between the distribution of various structural metrics and type categories of APIs. What impact it has on API RESTfulness. Top widely used APIs description documents will be analyzed and based on some metrics the structural analysis would be concluded to match it to some corresponding API characteristics.
This research question aims to answer if any relationship can be established between the result of the API structural analysis and its characteristics. RQ2 What are various design patterns and anti-patterns of REST API. Few research works have already defined a set of design patterns and anti-patterns of REST APIs but there has not been any concrete list. This project work intends to study the defined patterns and summarize them as well as research if any new pattern or anti-pattern is analyzed and can be introduced. RQ3 What is the possibility of the presence of few anti-patterns in the selected APIs. The analysis and result of research question 2 is the starting point for this research question. This question aims to detect the presence of a defined list of anti-patterns in the APIs structure design that have been selected for this study and conclude their presence and impact of the anti-patterns on the success popularity of the API. The paper is organized as follows. Section II briefly describes the Related work Section, III describes the methodology approach used for conducting this study, Section IV presents its analysis while Section V gives the results of the collected data, Section VI discusses the Threats to validity of the results of the study. A summary of the main results and a discussion of identified correlations and trends are provided in Section VII concludes the paper. II RELATED WORK. There are few research works published that talk about the structural analysis of the REST APIs The first research and analysis of REST APIs was conducted in 5 The authors investigated a set of 222 Web APIs taken from apigee com and ProgrammableWeb com popular Web API directories. The analysis was conducted manually and focuses on technical aspects of the selected APIs that are renowned I intend to manually select APIs from various categories and publish the results as compared to 5. Also the security or response code aspects not covered in 5 are also under the research lens in my project. The closest reference to my intended work is 7 which is the analysis of APIs based on machine-readable API descriptions. The analysis focuses on the structure of REST APIs and can be applied at design time, to improve the design of APIs. This improvement could lead to the API following strict REST principles and being RESTful. Researchers in 7 develop and use a canonical model to enhance the probability of their analysis. The aim of my project is to continue analysis on the structure of APIs using the description documents and developer guides of wide range of APIs and provide an overview or comment on the link between type category of APIs with its design factors.
I would cover the top and renowned APIs specific to each category to ensure diversification in analysis and results. It is important to design REST APIs of quality for building well maintainable and evolvable RESTful systems. In the literature, various design concerns are evaluated by the means of anti-patterns concept in terms of quality. The SOA Service Oriented Architecture community has defined the presence of various anti-patterns There are many sources that list the design patterns and anti-patterns like 8 9 and other sources on the Web The research paper 8 published the report of analysis of a set of 12 REST APIs with respect to a set of five patterns and eight antipatterns. The defined patterns and anti-patterns are displayed in Tables 1 and 2. TABLE 1 EIGHT DESIGN ANTI PATTERNS, TABLE 2 FIVE DESIGN PATTERNS. Based on the results authors define a detection algorithm both based on the observation and investigation of request and response messages exchanged with an API. The work of 8 is continued and extended in 10. Here the authors select a set of 15 REST APIs and concentrate on the analysis of URI structure using a set of five linguistic patterns and anti-patterns. The general analysis approach is the same as in 11. The whole process performed is semi-automatic. Each anti-pattern has a corresponding heuristics and detection algorithm which are applied to a set of request messages of the selected APIs. In this project, I aim to collect and summarize the design patterns and anti-patterns and later manually study and discover listed anti-patterns in some selected widely used REST APIs. III APPROACH ProgrammableWeb API directory is one of the largest API directories online containing 18370 Web APIs. I conducted the study by selecting APIs from the directory based on their categorization in the directory to provide wide area of API description analysis. On www programmableweb com the APIs are categorized based on their functional applications e.g Social, Mapping, Health Videos, Banking, Artificial Intelligence, Advertising, Analytics, Data as a Service Platform as a service etc.
The analyzed APIs were chosen based on their ranks in the directory. The directory consists of a relatively very large number of APIs which is not possible to be covered under the scope of this study hence I have taken 101 listed APIs under 12 categories from the directory. The chosen categories are Analytics, Email, Photos, Images, Social, Travel, File Sharing, Transportation, Blogging, Mapping, Banking, Health and Video. Within the mentioned categories APIs like Google Analytics, SendGrid, Yahoo, Mail, Gmail, MailChimp, Pinterest, Facebook, Twitter, LinkedIn, MySpace, Google Plus, Trip Advisor, Uber, Tumblr, WordPress org etc were considered as the data for this study. Each API description was analyzed to obtain information in terms of few features including general information of the API, its type its input parameters format of its output. Secure socket layer support details and other documentation. This analysis was conducted manually without involving any tool, Each API was examined in terms of 1 General description information. This group of information consists of the API name its description category number of mashups URL and number of operations. 2 Type of Web API It covers the architectural style of the Web API which could be REST RPC or hybrid. The aim of this research is to identify the RESTfulness of the APIs hence the ones that are not REST can be eliminated, 3 Input parameters. The APIs use optional parameters path parameters as well as query parameters and whether the parameters are Boolean. 4 Output formats Though JSON and XML are the most used output formats the description of APIs is analyzed to know other used output formats. 5 Authentication mechanism. Various APIs use different types of authentication methods to provide access to the API data. 6 SSL support whether the API provides SSL support for the communication data for the connection to the server. 7 Other documentation. Does the description document provide examples of requests response and error or response codes corresponding to an API. The focus of this study is to analyze these API features from description documents as they play an important role for different aspects of API usage. The analysis approach involved a sequence of simple steps. First 12 categories were browsed for picking up 5, 8 top APIs in each category to ensure domain-independent results. Later each API page was opened and general information was recorded.
Secondly, the API developer's guide was visited to find in-depth about the API operations. Out of all 101 selected APIs, only 8 websites were selected for analysis of operation, level, data. The remaining group of data was collected for all 101 APIs. The description forms and structures of each API had to be examined from scratch without being able to benefit from previous API analysis which made the whole process of this study slow. Based on the general Web API information the analysis highlighted that since all details are added manually to the Web API directory some of the feature descriptions were not always accurate. Sometimes the URL of the documentation had been moved or sometimes it was no longer available. Few APIs did not contain information about their authentication mechanism or input-output types. This is indicative for the difficulties resulting from using directories based on user entries. To determine the anti-patterns I selected the top 5 APIs from the previously selected 101 APIs to manually analyze their design looking for anti-patterns. The selected 5 APIs are of Dropbox Twitter Facebook Team Viewer and Best Buy With The help of POSTMAN extension in chrome I invoked the methods of these APIs and studied the response received. After analyzing the methods requests and responses the characteristics of each anti-pattern were checked for and if found present the results were recorded. Results show the presence of few anti-patterns in very famous and widely used APIs as presented in the Results section. V Presence of such anti-patterns does not create a state of error or issue Instead it is a sort of warning or caution that can be followed to ensure the compliance of REST APIs. IV ANALYSIS. In this section, the data collected during the study is described. The results are structured into 7 groups according to different parts of API descriptions that were analyzed. Each group provides valuable insights about separate aspects of the APIs and serves as the basis for identifying common characteristics and drawing conclusions. A General API Information.
The first baseline of information gathered here directly by browsing to the API page of the directory is the general API information. It contains some details provided directly by the API directory such as the name of the API its description, the category that it is assigned to the URI of the API and the latest update of the description. Table 3 provides the recorded numbers for these features. TABLE 3 GENERAL API INFORMATION. Description Maximum, Minimum, Average Categories under API 19 1 5. Number of operations 79 1 26. The number of mashups 2578 0 90. Each API taken into account had various functional categorizations under it. For example, Google Analytics Management had few functional categorizations namely. Account Summaries Accounts, AdWords, Links, Custom Data Sources, Filters, Goals etc. Each studied API had a minimum 1 functional category 5 as average overall for all APIs. The general API information collected also delivers some valuable insights about the granularity i.e the number of operations of the APIs. The maximum number of operations present under a single API was observed to be 79 and 26 is the average number of operations under an API. This leads us to the conclusion that the majority of the APIs are moderate, neither small nor too large and have very few operations except large APIs like Google. A mashup is a web application that uses content from more than one source i.e combines more than one API data to create a single new service. 1 ProgrammableWeb directory also presents the number of mashups for each API. The maximum number of mashups observed for an API understudy was 2578 that of Google Maps. An average number of mashups for an API was calculated to be around 90. It was observed that mostly the APIs that fell under the category of Mapping Location had more than the average number of mashups mentioned in Table 3. Finally, one observation made throughout the analysis was that since all details are added manually to the online API directory some of the descriptions were missing or not totally accurate.
This is especially true for the URL of the documentation which was sometimes moved or no longer available and for the authentication information which was very often missing or generalized. Even though online API directories are the easiest way to search for descriptions of a wide range of APIs there is a need for developing approaches to automate the process of analysis based on the usage. B Type of APIs. The selected APIs analyzed from the directory were identified to be of RESTful and RPC architectural styles. RESTful services are defined as services that conform to the representational state transfer. REST paradigm 6 REST is based on a set of constraints such as the client server-based communication statelessness of the request and the use of a uniform interface. A RESTful web service is commonly implemented by using HTTP comprising a collection of uniquely identified resources and their links to each other. In addition, RESTful services are characterized by resource representation decoupling so that resource content can be accessed via different formats. In comparison to RESTful APIs RPC style ones do not use directly the HTTP methods to access resources but rather define their own operations wrapping the resource information and then invoke these through one of the HTTP methods. 2 TABLE 4 TYPE OF APIS Description occurrence REST 94 9 RPC 5 05. Table 4 shows the distribution of different types of APIs. As it can be seen approximately 95 of the APIs were observed to follow REST architecture. C Input Parameters. The information in the API developer guides was thoroughly examined for 181 subs categorical APIs under 8 selected APIs. As it can be seen in Table 5 about 23 75 of APIs use optional parameters which may or may not be Boolean. 33 70 APIs used Boolean as optional input parameters. 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 the body. This has a strong effect on the matchmaking and invocation approaches since one API can be found or not depending on whether optional parameters are taken into account or not. Similarly, if the invocation is done on the basis of default values the output results can be drastically changed.
Formats like xml, json, pdf etc which may allow clients to develop in diverse languages a more flexible service consumption. 7 Tunneling Through GET Being the most fundamental HTTP method in REST the GET method retrieves a resource identified by a URI Developers often rely on GET methods to perform various operations like creation deletion or updating of a resource which is an inappropriate use of GET. 8 Tunneling Through POST This anti-pattern is very similar to the previous one except that in addition to the URI the body of the HTTP POST request may embody operations and parameters to apply on the resource RQ3. What is the possibility of the presence of a few anti-patterns in the selected APIs. As per the anti-pattern Breaking self descriptiveness REST developers tend to ignore the standardized data formats and protocols and are most likely to use their own header fields which limit the comprehension and reusability of REST APIs. As per the experiment all the APIs show some or the other anti-pattern in their design. For example methods in Facebook API had 5 instances, DropBox API had 4 instances, BestBuy API had 4 instances mostly using custom header fields, data formats, and protocols. For example, Facebook used x fb debug header field, which is mainly used to track a request-id for their internal bug management purpose. Similarly, I found DropBox using the x dropbox request-id and Twitter using x tfe logging request header fields. In general, the designers and implementers often distinguish the standardized and non-standardized header members by prefixing their names with x for experimental purposes and appending their API name to the header. The anti-pattern Forgetting Hypermedia was detected in 8 instances of methods of Facebook API and 8 instances of methods of DropBox API. This observation suggests that in practice developers sometimes do not provide hyperlinks in resource representations. Moreover Ignoring MIME Types antipattern was detected in 10 instances of Twitter and 7 instances of YouTube API methods. Few anti-patterns occur less frequently than the previously mentioned anti-patterns. Among them Ignoring Status Code and Misusing Cookies were not significantly observed among the tested methods of the selected APIs. Overall REST APIs that follow patterns tend to avoid corresponding antipatterns and vice versa. Finally, I found Facebook, DropBox and BestBuy APIs involved in only 3 instances of Ignoring MIME Types antipattern. VI THREATS TO VALIDITY.
The results presented for each research question involves a large number of APIs taken into consideration. I have tried to minimize the threats by diversifying the categories of APIs as well as taking APIs based on their ranks in each category. The external validity would not have major threats but as the process is done manually there may involve some case of internal validity which I could not verify due to the absence of such tools. My results for Research question 1 sort of match with the related work result except for few metrics as the type and number of APIs taken by me differs from the referred work. My findings of the Research question 3 match for some anti-patterns and differ for some mainly due to the process followed. I have performed the study manually whereas the referred work follows a semi-automatic approach involving a designed model. I believe that the last research question result can be improved by involving large number of APIs and matching with some automated approach to identify false positives and false negatives. VII CONCLUSION REST is now a popular architectural style for building Web-based applications REST developers may apply design patterns or introduce anti-patterns. These REST patterns and anti-patterns may respectively 1 facilitate and hinder semantically richer communications between clients and servers or, 2 ease and cause difficult maintenance and evolution. In this study, metrics are used to study high-level structure of the APIs using their description documents The API description documents are used as the starting point for the analysis. This information provides an overview of how APIs are developed and exposed what are its inputs and outputs, its protocols etc. In a thorough analysis of Research Question 1 this paper presents an investigation of seven groups of main characteristic features of a REST API. By using the data collected from the analysis we can better realize what the current difficulties are moreover also stated the distribution of various structural metrics among various categories of APIs. Discovering and analyzing the design patterns and anti-patterns of the REST APIs provides a base to improve the design of APIs or some cautionary points to keep in mind to ensure the optimum use of REST and HTTP principles while developing an API. Research question 2 details each and every design pattern and anti-pattern the way it is defined. Research question 3 proves that even if the API is successfully developed and used or renowned worldwide there is always a scope of improvement in the design. The improvement is only to optimize the performance or documentation not implementation.
The more compliant the API is to the principles the more RESTful it becomes automatically which is the main goal of this project. Future work for this project may involve automatization or semi automatization of the whole process by designing and implementing models to detect the structural analysis results when the description documents are fed to the model. For anti-pattern detection semi-automatic model already exists which can be optimized and progressed further REFERENCES.
Write and Proofread Your Essay
With Noplag Writing Assistance App