API Feasibility Study Report for The Piano and Keyboard Emporium

1. Introduction

This article focuses on conducting research on the online sales of a piano sales company, specifically exploring the feasibility of implementing API for online sales. In this article, I discuss the fundamental principles and technical foundations of various APIs and evaluate their feasibility, ultimately providing recommendations for the company.

1. Definition and Comparison of API

2.1 RESTful API

REST (Representational State Transfer) was first introduced by Roy Fielding, one of the primary authors of the HTTP specification, in his doctoral dissertation in 2000. In his paper, he stated, "The goal of this article is to understand and evaluate the architectural design of network-based application software that conforms to architectural principles, resulting in a highly functional, performant, and communicative architecture. REST refers to a set of architectural constraints and principles." [1] If an architecture adheres to the constraints and principles of REST, it is referred to as a RESTful architecture. REST itself is not a new technology but a set of structural constraints that guide the design and development of network-based application software. Initially, the REST architectural style was designed for all types of network application architectures, but it is now predominantly applied to HTTP and has become a popular architectural style in API interface design with the rise of distributed applications and microservices architectures. Taking resources as an example, the principles of REST primarily encompass aspects such as resource definition, resource retrieval, resource representation, and resource state transitions.

The benefits of RESTful APIs lie in their clear semantics and popularity. They are straightforward, standardized, and have conventions. However, their drawback is that they can be rigid, and adhering strictly to REST principles can be challenging for some. For certain requirements, REST may not be the most suitable solution, such as handling login actions.

2.2 GraphQL

GraphQL is a technology developed by Facebook that enables API queries based on a graph-like structure. It defines a specific Schema Definition Language (SDL) for defining the schema used for API queries. Let's briefly introduce several important concepts in GraphQL. Schema, also known as the schema, defines the queryable object types when accessing the GraphQL server API from a GraphQL client. One can consider a Schema as a presentation object model of the backend service. Type represents a type description in the GraphQL schema, corresponding to a class in the backend service. Field represents a description of a field in the Type of the GraphQL schema, corresponding to a field in a class of the backend service. Query is the unified query model for GraphQL protocol's query requests. It is the statement made by the GraphQL client to request data from the GraphQL server. A GraphQL request can be understood as a directed acyclic graph, where the Query serves as the entry point or root node. The root node can have multiple Schema child nodes (i.e., querying multiple backend interface models), and each Schema to be queried can have multiple field child nodes (i.e., the fields to be queried). In the GraphQL protocol, the values of all fields of a Type are obtained by the corresponding resolver functions bound to them. These resolver functions, also known as data fetchers, are responsible for fetching the data.

Under the GraphQL protocol, the server describes the available data types and structures for querying through the Schema. It specifies that the server must bind corresponding resolver functions for every field of each type provided by the Schema to obtain the query results of that field. This granularity of querying extends from object-level decomposition to field-level decomposition, providing the ability to query by specific fields [2]. GraphQL offers the capability for on-demand querying, which is highly flexible and eliminates the problem of query redundancy. For the server, the same model can be reused for multiple queries, reducing the number of interfaces that need to be maintained [3]. GraphQL also provides the mechanism for request merging, allowing clients to query multiple server schemas, corresponding to multiple backend interfaces, in a single HTTP request. This significantly reduces the frequency of interactions and the associated overhead between the GraphQL client and server. Additionally, GraphQL is a strongly typed language. In contrast to the uncertainty of data interactions using JSON format in RESTful APIs, GraphQL allows the server to ensure the shape and characteristics of the returned values during the development phase. The GraphQL server's type system can handle parameter validation, not only checking the syntax correctness of a request but also verifying its unambiguousness and absence of errors within the given GraphQL Schema's contextual environment. Moreover, GraphQL schemas, written in strongly typed languages, enforce writing comments as part of the code, making the code itself serve as documentation. This reduces the burden on backend developers and makes the interfaces more robust. These features make GraphQL a versatile API querying solution applicable to various querying scenarios. For example, it can be used as an aggregation entry API for database queries or as a gateway responsible for routing frontend and backend interactions.

3. Solution Recommendation

The simplicity of RESTful APIs means that they are easier for beginners and experienced developers to understand and implement, making them an ideal choice for teams with limited API development experience. Meanwhile, its powerful integration capability ensures seamless integration with existing C #, PostgreSQL, and PHP technology stacks, further improving the overall efficiency and stability of the system. Considering the future growth of the business, the scalability of RESTful APIs ensures that the system can cope with constantly growing demands while maintaining excellent performance and reliability.

4. Software Architecture Design

In the backend, I chose Node.js as the main language because it performs well in handling a large number of concurrent requests and is suitable for the development of RESTful APIs. In order to build these APIs more efficiently, I adopted the Express.js framework, which provides rich routing and middleware support, making API development concise and fast. In terms of data storage, I chose the PostgreSQL database not only because it has powerful transaction processing and data integrity assurance, but also because the team already has relevant professional knowledge to quickly design and optimize the database.

1. Conclusion

In summary, considering the specific needs of online score subscription business and my in-depth evaluation of API architecture style, I strongly recommend adopting RESTful API architecture. This decision not only meets the customer's requirements for system simplicity, integration, and scalability, but also fully utilizes my existing professional knowledge and technical stack. The adoption of RESTful APIs will ensure that the system can flexibly respond to business growth while maintaining excellent performance and stability. Therefore, this solution is an ideal choice to meet customer needs, achieve business goals, and drive technological development.

References:

[1]Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation[D], University of California, Irvine,2000.

[2] Hartig, Olaf, and Javier Pérez.. Semantics and Complexity of GraphQL[C/OL]] // CHAMPIN P, GANDON F L, LALMAS M, et al. Proceedings of the 2018 April 23-27,2018. [S.l.] : ACM, 2018 : 1155 – 1164.https://doi.org/10.1145/3178876.3186014.

[3] Taelman, René, Markus V. Sande, and Robert Verborgh. GraphQL-LD: Linked Data Querying with GraphQL[C/OL] // van ERP M, ATRE M, LÓPEZ V, et al. CEUR Workshop Proceedings, Vol 2180 : Proceedings of the ISWC 2018 Posters & Demonstrations, Industry and Blue Sky Ideas Tracks co-located with 17th International Semantic Web Conference (ISWC 2018), Monterey, USA, October 8th -to - 12th, 2018. [S.l.] : CEUR-WS.org, 2018. http://ceur-ws.org/Vol-2180/paper-65.pdf.