Web API代写｜6003CEM – Web API Development-CW1

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:
a)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.
b)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.