Application Programming Interface (API)

Chapter 1

INTRODUCTION

Application programming interfaces (API) simplify software development and innovation by enabling applications to exchange data and functionality easily and securely.

An API is a set of defined rules that explain how computers or applications communicate with one another. API’s sit between an application and the web server, acting as an intermediary layer that processes data transfer between systems.

1.1 Working Of API

1. A client application initiates an API call to retrieve information—also known as a request. This request is processed from an application to the web server via the API’s Uniform Resource Identifier (URI) and includes a request verb, headers, and sometimes, a request body.
2. After receiving a valid request, the API makes a call to the external program or web server.
3. The server sends a response to the API with the requested information.
4. The API transfers the data to the initial requesting application.

Typically, API’s use JSON (Javascript Object Notation) as the main language which provides methods designed to extract and manipulate data stored in HTML documents.

API’s aggregate data and complete processes over completely disparate systems, allowing them to interact with each other. In layman’s terms, think of them as a waiter in a restaurant.

A waiter takes the order from the customer which is then relayed to the chef. Once the chef completes the meal, the waiter brings the meal to the customer. Similarly, an API receives a request from an application. It then interacts with a foreign server/data source to collect and process a response, which is then returned to the application.

In recent years, the popularity and usage of API’s have increased exponentially. A recent study found that two-thirds of developers expected to increase their usage of API’s in 2020. Additionally, companies across industries continue to develop and use API’s as a critical part of their strategy. By exposing often complex services as simplified code, API’s are easy to integrate and potential use cases are unlimited.

1.2 Need For API’s 

1. Improved collaboration The average enterprise uses almost 1,200 cloud applications, many of which are disconnected. APIs enable integration so that these platforms and apps can seamlessly communicate with one another. Through this integration, companies can automate workflows and improve workplace collaboration. Without APIs, many enterprises would lack connectivity and would suffer from informational processes that comprise productivity and performance.
2. Easier innovation APIs offer flexibility, allowing companies to make connections with new business partners, offer new services to their existing market, and, ultimately, access new markets that can generate massive returns and drive digital transformation. For example, the company Stripe began as an API with just seven lines of code. The company has since partnered with many of the biggest enterprises in the world, diversified to offer loans and corporate cards, and was recently valued at USD 36 billion.
3. Data monetization Many companies choose to offer APIs for free, at least initially, so that they can build an audience of developers around their brand and forge relationships with potential business partners. However, if the API grants access to valuable digital assets, it can monetize it by selling access (this is referred to as the API economy). When AccuWeather launched its self-service developer portal to sell a wide range of API packages, it took just 10 months to attract 24,000 developers, selling 11,000 API keys and building a thriving community in the process.
4. Added security As noted above, APIs create an added layer of protection between the data and a server. Developers can further strengthen API security by using authentication tokens, signatures, and Transport Layer Security (TLS) encryption, by implementing API gateways to manage and authenticate traffic  and by practicing effective API management.

Chapter 2

LITERATURE SURVEY

A literature review is the synthesis of the available literature regarding your research topic. This synthesis merges the conclusions of many different sources to explain the overall understanding of the topic, thus laying a foundation for both the research question and primary research. So here are some papers with reference to API.

W. Zhou et al proposed REST API Design Patterns for SDN Northbound API. This paper proposes a REST architectural style gaining increasing popularity in the networking protocol design, and it has become a prevalent choice for northbound API of Software-Defined Networking (SDN). This paper addresses many critical issues in RESTful networking protocol design, and presents a framework on how a networking protocol can be designed in a truly RESTful manner, making it towards a service oriented data networking. In particular, we introduce the HTTP content negotiation mechanism which allows clients to select different representation formats from the same resource URI[1].

S. T. Febrian et al proposed API Adapter for Payment Gateway Variation Development in Software Product Line Engineering In this paper a payment gateway is an e-commerce service that automatically processes and verifies money transactions. Many payment gateways can be integrated as a software feature, where each software product has their preferences. To accommodate that use of Software Product Line Engineering (SPLE) paradigm, which maximizes the reusability and composition to develop a family of products with less production cost than conventional methods.The development of the payment gateway feature using SPLE-based development tools, which is ABS-Microservices Framework, Also development the API Adapter during the development process, which is required to enable communication with the payment gateway provider[2].

L. Li et al proposed Design Patterns and Extensibility of REST API for Networking Applications. In this paper, discussion on  REST architectural style has become a prevalent choice for distributed resources, such as the northbound API of software-defined networking (SDN). As services often undergo frequent changes and updates, the corresponding REST APIs need to change and update accordingly. To allow REST APIs to change and evolve without breaking its clients, a REST API can be designed to facilitate hypertext-driven navigation and its related mechanisms to deal with structure changes in the API. This paper addresses the issues in hypertext-driven navigation in REST APIs from three aspects. First, we present REST Chart, a Petri-Net-based REST service description framework and language to design extensible REST APIs, and it is applied to cope with the rapid evolution of SDN northbound APIs. Second, we describe some important design patterns, such as backtracking and generator, within the REST Chart framework to navigate through large scale APIs in the RESTful architecture[3].

F. Maurer et al proposed A study of the effectiveness of usage examples in REST API documentation This paper proposes Generating and maintaining REST API documentation with usage examples can be a time consuming and expensive process for evolving APIs. Most REST API documentation tools focus on automating the documentation of the API objects, but require manual effort for capturing usage examples. Consequently, REST API developers need to know the cost vs. benefit of providing usage examples in the documentation to prioritize the documentation efforts[5].

L. Li et al proposed Designing Large Scale REST APIs Based on REST Chart. This paper presents two important enhancements and extensions to REST Chart modeling - Hyperlink Decoration and Hierarchical REST Chart. In particular, the proposed Hyperlink Decoration decomposes resource connections from resource representation, such that hyperlinks can be defined independently of schemas. This allows a Navigation-First Design by which the important global connections of a REST API can be designed first and reused before the local resource representations are implemented and specified. Hierarchical REST Chart is a powerful mechanism to rapidly decompose and extend a REST API in several dimensions based on Hyperlink Decoration. These new mechanisms can be used to manage the complexities in large scale REST APIs that undergo frequent changes as in some large scale open source development projects[6].

Chapter 3

METHODOLOGY Of API

API gateways, which are a part of API management tools, are used to intercept all incoming requests, and manage all the authentication, rate limiting, billing and analytics. API gateways provide a single point of entry to your applications, which bundle or encapsulate the internal software architecture and also help in providing APIs tailored to different clients.

3.1 Types of API’s

Most APIs are web APIs—APIs that expose an application's data or functionality to a web browser, mobile device or other client over the internet. Web API calls can be made using any programming language, or by web pages using HTML. There are four main types of web API:

1. Open APIs are open source application programming interfaces you can access with the HTTP protocol. Also known as public APIs, they have defined API endpoints and request and response formats.
2. Partner APIs are application programming interfaces exposed to or by strategic business partners. Typically, developers can access these APIs in self-service mode through a public API developer portal. Still, they will need to complete an onboarding process and get login credentials to access partner APIs.
3. Internal APIs are application programming interfaces that remain hidden from external users. These private APIs aren't available for users outside of the company and are instead intended to improve productivity and communication across different internal development teams.
4. Composite APIs combine multiple data or service APIs. These services allow developers to access several endpoints in a single call. Composite APIs are useful in microservices architecture where performing a single task may require information from several sources.

(Note: All web APIs are remote APIs that call functions or operate on data or resources that reside on a computer other than the computer making the request.)

Different use cases call for different implementations and architectures. This also means different accepted data types and commands.

3.2 Types of API Protocols

As the use of web APIs has increased, certain protocols have been developed to provide users with a set of defined rules that specifies the accepted data types and commands. In effect, these API protocols facilitate standardized information exchange:

1. SOAP (Simple Object Access Protocol) is an API protocol built with XML, enabling users to send and receive data through SMTP and HTTP. With SOAP APIs, it is easier to share information between apps or software components that are running in different environments or written in different languages.
2. XML-RPC (Extended Markup Language - Remote Procedure Call) is a protocol that relies on a specific format of XML to transfer data, whereas SOAP uses a proprietary XML format. XML-RPC is older than SOAP, but much simpler, and relatively lightweight in that it uses minimum bandwidth.
3. JSON-RPC (JavaScript Object Notation Remote Procedure Call) is a protocol similar to XML-RPC, as they are both remote procedure calls (RPCs), but this one uses JSON instead of XML format to transfer data. Both protocols are simple. While calls may contain multiple parameters, they only expect one result.
4. REST (Representational State Transfer) is a set of web API architecture principles, which means there are no official standards (unlike those with a protocol). To be a REST API (also known as a RESTful API), the interface must adhere to certain architectural constraints. It’s possible to build RESTful APIs with SOAP protocols, but the two standards are usually viewed as competing specifications.

REST APIs are based on URLs and the HTTP protocol and are based on these 6 architectural constraints:

1. Client-server based - The client handles the front end process while the server handles the backend and can be both replaced independently of each other.
2. Uniform interface - Defines the interface between client and server and simplifies the architecture to enable each part to develop separately
3. Stateless - Each request from client to server must be independent and contain all of the necessary information so that the server can understand and process it accordingly.
4. Cacheable - Maintains cached responses between client and server avoiding any additional processing
5. Layered system - Layers are arranged hierarchically so that each one can only ‘see’ the corresponding layer they are interacting with.
6. Code-on-demand - Allows client functionality to be extended by downloading and executing code in the form of applets and scripts. This simplifies clients by reducing the number of features required to be pre-implemented.

Once following these defined constraints the API created is said to be RESTful.

APIs make software development easier and faster. The complexity in including or building on new features is reduced because of the abstraction that an API provides, and also the data and resources can be used easily across applications.

3.3 Working Principle of API

A web service is a software component that can be accessed via a web address. Therefore, by definition, web services require a network. As a web service exposes an application’s data and functionality, in effect, every web service is an API. However, not every API is a web service.

Traditionally, API referred to an interface connected to an application that may have been created with any of the low-level programming languages, such as Javascript. The modern API adheres to REST principles and the JSON format and is typically built for HTTP, resulting in developer-friendly interfaces that are easily accessible and widely understood by applications written in Java, Ruby, Python, and many other languages. 

When using APIs, there are two common architectural approaches: Service Oriented Architecture (SOA) and microservices architecture.

1. SOA is a software design style where the features are split up and made available as separate services within a network. Typically, SOA is implemented with web services, making the functional building blocks accessible through standard communication protocols. Developers can build these services from scratch, but they usually create them by exposing functions from legacy systems as service interfaces.
2. Microservices architecture is an alternative architectural style that divides an application into smaller, independent components. Applying the application as a collection of separate services makes it easier to test, maintain, and scale. This methodology has risen to prominence throughout the cloud computing age, enabling developers to work on one component independent of the others.

While SOA was a vital evolutionary step in application development, microservices architecture is built to scale, providing developers and enterprises with the agility and flexibility they need to create, modify, test, and deploy applications at a granular level, with shorter iteration cycles and more efficient use of cloud computing resources.

Chapter 4

ADVANTAGES

1. Automation with APIs, computers rather than people can manage the work. Through APIs, agencies can update workflows to make them quicker and more productive.
2. Application because APIs can access the app components, the delivery of services and information is more flexible.
3. More scope with an API an application layer can be created which can be used to distribute information and services to new audiences which can be personalized to create custom user experiences
4. New data available an API allows all of the information generated at the government level to be available to every citizen, not just a select few.
5. Efficiency when access is provided to an API, the content generated can be published automatically and is available for every channel. It allows it to be shared and distributed more easily.
6. Integration APIs allow content to be embedded from any site or application more easily. This guarantees more fluid information delivery and an integrated user experience.
7. Personalization through APIs any user or company can customize the content and services that they use the most.
8. Adaptation needs change over time and APIs help to anticipate changes. When working with this technology, data migration is supported better, and the information is reviewed more closely. In short, APIs make service provision more flexible.

Chapter 5

APPLICATIONS

1. Universal logins: A popular API example is the function that enables people to log in to websites by using their Facebook, Twitter, or Google profile login details. This convenient feature allows any website to leverage an API from one of the more popular services to quickly authenticate the user, saving them the time and hassle of setting up a new profile for every website service or new membership.
2. Third-party payment processing: For example, the now-ubiquitous "Pay with PayPal" function you see on ecommerce websites works through an API. This allows people to pay for products online without exposing any sensitive data or granting access to unauthorized individuals.
3. Travel booking comparisons: Travel booking sites aggregate thousands of flights, showcasing the cheapest options for every date and destination. This service is made possible through APIs that provide application users with access to the latest information about availability from hotels and airlines. With an autonomous exchange of data and requests, APIs dramatically reduce the time and effort involved in checking for available flights or accommodation.
4. Google Maps: One of the most common examples of a good API is the Google Maps service. In addition to the core APIs that display static or interactive maps, the app utilizes other APIs and features to provide users with directions or points of interest. Through geolocation and multiple data layers, you can communicate with the Maps API when plotting travel routes or tracking items on the move, such as a delivery vehicle.
5. Twitter: Each Tweet contains descriptive core attributes, including an author, a unique ID, a message, a timestamp when it was posted, and geolocation metadata. Twitter makes public Tweets and replies available to developers and allows developers to post Tweets via the company's API.

Chapter 6

CONCLUSION

As APIs are an integral part of software development, which makes the whole process more understandable, less complex and more efficient. It also helps developers and businesses to collaborate with each other to build some exciting services.

They remove previous barriers with just a few taps or clicks and can easily be integrated. Just think of them as waiters going back and forth between delivering data and creating interconnectivity.The possibilities are truly endless.

REFERENCES

1. W. Zhou, L. Li, M. Luo and W. Chou, "REST API Design Patterns for SDN Northbound API," 2014 28th International Conference on Advanced Information Networking and Applications Workshops, 2014, pp. 358-365, doi: 10.1109/WAINA.2014.153.
2. S. T. Febrian, O. Komarudin and A. Azurat, "API Adapter for Payment Gateway Variation Development in Software Product Line Engineering," 2021 International Conference on Advanced Computer Science and Information Systems (ICACSIS), 2021, pp. 1-6, doi: 10.1109/ICACSIS53237.2021.9631355.
3. L. Li, W. Chou, W. Zhou and M. Luo, "Design Patterns and Extensibility of REST API for Networking Applications," in IEEE Transactions on Network and Service Management, vol. 13, no. 1, pp. 154-167, March 2016, doi: 10.1109/TNSM.2016.2516946
4. Xiang-Wen Huang, Chin-Yun Hsieh, Cheng Hao Wu and Yu Chin Cheng, "A Token-Based User Authentication Mechanism for Data Exchange in RESTful API," 2015 18th International Conference on Network-Based Information Systems, 2015, pp. 601-606, doi: 10.1109/NBiS.2015.89.
5. S. M. Sohan, F. Maurer, C. Anslow and M. P. Robillard, "A study of the effectiveness of usage examples in REST API documentation," 2017 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), 2017, pp. 53-61, doi: 10.1109/VLHCC.2017.8103450.
6. L. Li and W. Chou, "Designing Large Scale REST APIs Based on REST Chart," 2015 IEEE International Conference on Web Services, 2015, pp. 631-638, doi: 10.1109/ICWS.2015.89.