这是一篇来自英国的关于Web API开发代写的作业案例，具体要求是一家英国公司希望开发一个独立的网站和移动应用程序来销售他们的产品，该网站的移动应用程序将快速更新为早期版本。因此，他们需要在其全堆栈web应用程序框架中选择并实现基于http的API（Web API），以便于开发人员更容易地升级他们的应用程序

Introduction

With the development of the Internet, according to Jacobson (2012), various Internet companies have begun to attach importance to the business of API, such as AWS of Amazon, which provides customers with cloud computing, cloud storage, IT infrastructure services, or real-time translation on various translation software is also a kind of application of API.

Now, a UK company hopes to develop a standalone website and mobile application to sell their product, with the mobile application for the website to be quickly updated in early versions. Therefore, they need to choose and implement HTTP-based API (Web API) in their full-stack web application framework to make it easier for developers to upgrade their applications. While the company’s developers had experience with Microsoft C# desktop applications, PostgreSQL, external API, and PHP web site use and management, no technical staff had experience with full-stack Web application development and API development, so they wanted a viable API solution.

This report will explain and define API, compare several Web API architectural styles, and then design a web full stack application framework that uses API based on the customer’s existing technologies and requirements.

3 styles of the web API specifications/protocols

SOAP

Box (2000) claims that SOAP is a web communication protocol that is highly standardized in XML format. XML data format has a large number of message structures which makes it the most detailed API style. It with built-in WEB services capabilities to handle both incoming and outgoing messages, and it can be tied to a variety of protocols for every situation. Finally, it has the highest security factor among the 3 protocols, because it has a series of security extensions, it can be integrated with ES-Security, so it is very suitable for enterprise-level transactions, because it maintains the integrity of the transaction while allowing encryption at the message level.

However, AlShahwan (2010) has a different attitude towards SOAP. He points out that XML contains too much data,SOAP requires fast broadband, and SOAP requires very specialized knowledge to build apis, so it requires high learning costs for enterprise hardware facilities and technical personnel.

REST

REST (Resource Representational State Transfer) is the “state shift” of resources in a certain “representation” during network transmission. Kurtz (2014) indicates that REST is a simple alternative to SOAP. It is a style of software architecture used to work by http, takes data as resources and each resource is represented by a unique URL that can be requested by providing its URL. Compared with SOAP’s strictly defined API specifications, REST can return data not only in XML format, but also in JSON, HTML and other formats, so REST is easier to use than SOAP.

In addition to the benefit of supporting multiple formats, REST is lightweight (cache-friendly) because it reuses many http tools and is the only API framework that can cache data at the http level. Finally, the REST communication between client and server shows everything so it is discoverable.

But Tilkov, S. (2007) points out that REST is less secure than SOAP because it supports authentication and communication encryption through TLS, whereas SOAP is well standardized through WS-SECURITY. In addition, REST often returns large amounts of data, over-fetching or under-fetching.

GraphQL

GraphQL is a query language and execution engine that describes the capabilities and requirements of your application’s data model through an API. Brito(2019) claimed that GraphQL was originally created by Facebook as a syntax describing how to send accurate data requests in order to solve the problem of excessive REST returned data. Its advantage was to simplify the content of request and response without any redundant data. The front end can decide what data the back-end returns.

Therefore it is ideal for microservices, mobile applications, and complex systems. But not everyone has enough time to get the hang of it.

Solution Recommendation

In this project, I will recommend using the API of the REST architecture. The reasons are as follows:

Support for more flexible data formats

REST supports a variety of data formats, such as CSV, JSON, and RSS. We can get the desired output in a form that is easy to parse in the language required by the application. SOAP relies entirely on XML to provide messaging services that can become very complex in some cases, such as Web services accessed through JavaScript. The GraphQL service typically returns data in JSON format. Neither SOAP nor GraphQL meets the flexible requirements scenarios.

Simple implementation

Setting up REST in a Web server application is simple, especially if we are working with a few frameworks. Laravel, for example, express, django springboot etc., they all provides a very convenient way to implement the REST interface. GraphQL is more difficult to implement than REST. The IT department at the client company does not currently have the expertise to apply the harder-to-learn technologies.

I recommend REST for the above two reasons.

The suggested tech stack is as follows:

Web server

Use NodeJS to set up the Web server, while using the express framework to construct different REST APIs. This is because Nodejs syntax is completely JavaScript syntax, short development cycle, low development cost, low learning cost, can achieve high performance server. Connect Node applications to the PostgreSQL database using the Node-Postgres module.

Database and Desktop

Using the existing PostgreSQL database and C# client, there is no need to repeat development.

Website

Use PHP technology that the IT department already knows to build the website.

Mobile Application

Use HTML5 to build mobile apps. HTML5 is easy to learn, quick to build apps, and supports both Android and IOS devices.

The C4 model is as follows: