Categories
Uncategorized

Datasta myytävä palvelu?

Kirjoittaja Tampereen yliopisto, Prof. Marko Seppänen

Categories
Uncategorized

API-ekosysteemien liiketoiminta

Kirjoittanut Eveliina Saari

API-ekosysteemit muodostuvat joukosta partnereita, jotka hyödyntävät toistensa rajapintoja ja vuorovaikutusta kehittäessään omia tuotteitaan. API-ekosysteemillä on yhteinen arvolupaus, jonka osapuolet pyrkivät materialisoimaan tuottamalla uusia ratkaisuja tai palveluita. (Adner 2017, Moilanen et al. 2018, Manikas & Hansen 2013) Esimerkki API-ekosysteemistä on avoimen pankkitoiminnan muodostama API-ekosysteemi. Euroopan Unionin toinen maksupalveludirektiivi (EU) 2015/2366 (Payment Services Directive 2) eli PSD2 on vaikuttanut avoimen pankkitoiminnan laajenemiseen Euroopan alueella.

PSD2:n mukaisesti pankkien tulee tarjota avoimia API-ratkaisuja kolmannen osapuolen palveluntarjoajille. Nämä kolmannet palveluntarjoajat voivat kehittää pankkitoimintaan tarvittavia teknologisia ratkaisuja itse tai hyödyntää teknisiä palveluntarjoajia. (Farrow 2020b) Kolmansia palveluntarjoajia, jotka kehittävät ja hyödyntävät finanssiteknologiaa itse, voidaan kutsua fintech-palveluntarjoajiksi (Lee & Shin 2018). Pankin, kolmansien palveluntarjoajien, fintech-palveluntarjoajien, teknisten palveluntarjoajien, ohjelmistokehittäjien sekä maksupalvelun käyttäjien lisäksi ekosysteemiin kuuluu myös rahoitusalan sääntelyviranomaisia (Lee & Shin 2018). Kuvassa 1 esitellään avoimen pankkitoiminnan ekosysteemin osapuolien yhteyksiä toisiinsa.

Kuva 1. Avoimen pankkitoiminnan API-ekosysteemin osapuolet (inspiroinut Farrow 2020a, Farrow 2020b, Lee & Shin 2018)

API-ekosysteemeissä tärkein asiakassuhde muodostuu API-tarjoajien ja API-hyödyntäjien välille, koska näiden suhteiden laatu vaikuttaa siihen, haluavatko API-hyödyntäjät käyttää API-ratkaisuja myös jatkossa, mikä vaikuttaa koko ekosysteemin toimintaan. (Moilanen et al. 2018, Jacobson et al. 2011). Arvonluonti ja liiketoimintamahdollisuudet API-ekosysteemeissä liittyvät kolmeen näkökulmaan: yhteistyöhän ekosysteemissä, teknologisuuteen ja strategiseen liiketoimintaan.

Kaikilla ekosysteemin osapuolilla on omia liiketoiminnallisia tavoitteitaan, mutta jokainen osapuoli voi APIen kautta tarjota omia resurssejaan myös muiden hyödynnettäväksi. Resursseja hyödyntämällä ekosysteemin osapuolet voivat kehittää yhdessä innovatiivisia palveluita ja tuotteita, joiden avulla voidaan palvella loppuasiakkaita paremmin (Omarini 2018, Premchand & Choudhry 2019). Esimerkiksi avoimessa pankkitoiminnassa uudet palvelut voivat houkutella lisää uusia asiakkaita, jotka antavat yhä useammin uusille kolmansille palveluntarjoajille suostumuksensa pankkitilien käyttöön. Tällöin asiakasdatan määrä kasvaa ja sitä analysoimalla mahdollistetaan entistä parempien palvelujen innovointi ja kehitys. (Farrow 2020b) Avoimen pankkitoiminnan arvonluontiketju on kuvattu kuvassa 2.

Kuva 2. Avoimen pankkitoiminnan arvosykli maksutoimeksiantopalvelun tarjoajan alustalla (mukailtu Farrow 2020b)

API-ekosysteemeissä osapuolten tulee hyödyntää etenkin API-teknologiaa, jonka kehittämisessä ja hallinnoimisessa voi kuitenkin hyödyntää muita yrityksiä, kuten teknisiä palveluntarjoajia. Avoimessa pankkitoiminnassa erityisesti fintech-palveluntarjoajien teknologiset resurssit yhdistettynä pankkipalveluiden tarjoamiseen mahdollistaa uusien innovatiivisten pankkipalveluiden kehityksen, joka johtaa asiakasarvon lisääntymiseen koko ekosysteemissä (Farrow 2020b). Näin tapahtuu myös kuvan 2 arvoketjussa.

APIen hyödyntäminen ja erityisesti API-ekosysteemin rakentaminen voi olla strategisesti suuri muutos liiketoiminnalle (Omarini 2018). APIen hyödyntämisen tai tarjoamisen voi aloittaa kuitenkin eri tavoin. Esimerkiksi avoimessa pankkitoiminnassa pankit voivat mukautua PSD2:n vaatimuksiin tarjoamalla mahdollisimman vähän dataa ja toiminnallisuuksia muiden palveluntarjoajien käytettäväksi tai hyödyntää avointa pankkitoimintaa myös omassa liiketoiminnassaan pyrkimällä luomaan uusia tulovirtoja esimerkiksi uusien kumppaniorganisaatioiden tai muiden kolmansien palveluntarjoajien kanssa (Omarini 2018, Hadad 2019). Tarkkaan mietittyjen liiketoimintastrategioiden avulla pankeilla on mahdollisuuksia luoda uusia tulovirtoja esimerkiksi tarjoamalla lisää dataa ja toiminnallisuuksia myös maksullisten APIen kautta (Farrow 2020a). Pankit voivat houkutella kolmansia palveluntarjoajia käyttämään maksullista APIa ja kehittää palveluitaan paremmiksi, mikä luo samalla arvoa pankille. Uusien palveluiden kehitys voi synnyttää myös uusia kumppanuussuhteita pankkien ja kolmansien palveluntarjoajien välille. (Westermeier 2020, Omarini 2018, Svensson et al. 2019) Uusien kumppanuuksien avulla osapuolet voivat luoda uusia tulovirtoja, arvoa ja liiketoimintamahdollisuuksia sekä itselleen että koko API-ekosysteemille.

Lähteet:

Farrow, G. 2020a. An Application Programming Interface Model for Open Banking Ecosystems. Journal of Payments Strategy & Systems. Vol. 14:1, 75-91. ISSN 1750-1806.

Farrow, G. 2020b. Open Banking: The Rise of the Cloud Platform. Journal of Payments Strategy & Systems. Vol. 14:2, 128-146. ISSN 1750-1806.

Hadad, S. 2019. Challenges for Banking Services in the Knowledge Economy. Management Dynamics in the Knowledge Economy. Vol. 7:3, 337-352. ISSN 2392-8042.

Jacobson, D., Brail, G., Woods, D., Treseler, M. and Romano, R. 2011. APIs: a strategy guide. Farnham: O’Reilly. ISBN 1-4493-0892-9.

Lee, I. and Shin, Y.J. 2018. Fintech: Ecosystem, Business Models, Investment Decisions, and Challenges. Business Horizons. Vol. 61:1, 35–46. ISSN 0007-6813.

Moilanen, J., Niinioja, M., Seppänen, M. and Honkanen, M. 2018. API-talous 101. Helsinki: Alma Talent. 235 s. ISBN 978-952-14-3508-9.

Omarini, A. 2018. Banks and Fintechs: How to Develop a Digital Open Banking Approach for the Bank’s Future. International Business Research (Toronto). Vol. 11:9, 23 s. ISSN 1913-9004.

Premchand, A. and Choudhry, A. 2019. Open Banking and APIs for Transformation in BankingAnonymous 2018 International Conference on Communication, Computing and Internet of Things (IC3IoT). 15-17 Feb. 2018. IEEE, 25-29. ISSN 9781-538624586.

Svensson, C., Udesen, J. and Webb, J. 2019. Alliances in Financial Ecosystems: A Source of Organizational Legitimacy for Fintech Startups and Incumbents. Technology Innovation Management Review. Vol. 9:1, 20–32. ISSN 1927-0321.

Westermeier, C. 2020. Money is Data – the Platformization of Financial Transactions. Information, Communication & Society. Vol. 23:14, 2047-2063. ISSN 1369-118X.

Categories
Uncategorized

Highlights of the 4APIs final seminar 24.3.2021

“The API is the key to access to the power. Build your ecosystem around a customer journey.” Amancio Bouza

“Business model is not the same as revenue model. API monetization is as much about creating in-direct value of all kinds as it is about creating direct value, one area of value creation being revenue streams directly from APIs”. Marjukka Niinioja

“Start your data productization planning from the customers – who are the customers?” Toni Luhti and Jarkko Moilanen

“Mobility as a Service (MaasS). APIs can create new industries in mobility services in cities.” Hendrik Wolff

If interested of the issues, you can contact us.

Categories
Demos

Using GraphQL Faker with portcall and pilotage order data

Author: Janne Nissinen, a developer at Solita

Solita’s API roadmap contained a task to create a proof of concept of aggregating two data sources together. Both of these APIs contained valuable information of the ship traffic, and by providing an aggregated data endpoint could provide some value to its users.

GraphQL and its extended faker-plugin were used to create several prototypes of the data structure with minimum amount of actual data merging. GraphQL-faker allows users to host local endpoints for development purposes. Furthermore, it allows its users to extend pre-existing GraphQL–services and modify their data structure to suit the users’ needs.

Figure 1 – Graphql-faker editor in browser

For the given task, each individual APIs data structure was studied, and similar data nodes were given a specific type, which resembles a data structure in GraphQL. For example, Port is a type which contains two text-based fields code and name, which will resemble the actual Port values. It also contains a nested type Location, which provide location data for the given parent type. By using the faker, no aggregation is needed to produce actual values, since the faker allows its users to pass example data in, which are then given back randomly when the port is queried.

Figure 2 – Port–type queried, faked data returned

As a proof of concept, data aggregation and data structure-based prototyping is doable and fast using GraphQL and its faker–plugin. For further iterations, both existing APIs need to be studied and the type structure needs to be honed down further to provide actual value to its users.

Categories
Uncategorized

Onnea Vaadin!

Uudet kasvumoottoriekosysteemit käyntiin: miljardikasvua odotetaan autonomisesta liikenteestä, digitaalisista alustoista ja muovin poistamisesta vesistöistä – Business Finland

Business Finland on valinnut uusimman kasvumoottorikilpailutuksen voittajiksi neljä yritystä: Unikie, Vaadin, Family in Music ja Lamor. Kukin yritys on sitoutunut tavoittelemaan vähintään miljardin euron edestä uutta innovaatiolähtöistä liiketoimintaa ekosysteemeissään, joiden avainyrityksinä ne toimivat. Kasvumoottoreita toteutetaan yritysvetoisella yritysten, tutkimusorganisaatioiden ja julkisten toimijoiden kumppanuusmallilla.

Lähde: Business Finland 2020

Categories
Uncategorized

Great applications are built on forgettable APIs

Written by Vaadin Leif Åstrand

An API is an interface that application developers use to make their application interact with some other application, or another part of the same application if it has modular structure. The purpose of this interaction is to transmit some kind of data between the applications, such as fetching the latest weather forecast or submitting tax records to the appropriate authorities. The API defines how the data should be structured in different types of messages sent between the communicating parties.

At the end of the day, the purpose of data and applications is to serve the needs of human users. The relationship is sometimes only indirect in case there are multiple intermediate applications passing data between each other before it reaches the application that the user is using. Since humans and computers have quite different means of communication, a different type of interface is needed instead of an API. This is the user interface, or UI.

From the point of view of an application user, the UI is all that matters. Everything else is an implementation detail to them. They only care about getting their job done as efficiently as possible, but they aren’t concerned about how that is carried out. API use matters no more than any other technicalitty such as which programming language is used to implement the application or what kind of hardware is used to host any server-side functionality of the application.

Application developers serve their users

It is the application developer’s job to make all of this come true for the end user. They should design and implement the UI based on the needs of the user and not based on what’s convenient with the APIs they are using. If the API uses a weird format or structure for its data, then the application should take care of converting that to something that makes sense for the user. If there is a risk that the API isn’t always available, then the application developer should ensure suitable fallbacks are in place. Finally, the application needs to mitigate the risk that the API might change in the future.

From a more practical point of view, this typically means that the application should use an anti-corruption layer between the API and the rest of the application. This makes the API quite forgettable since developers working on other parts of the application won’t have to remember all the details that are encapsulated in the anti-corruption layer. Encapsulating the API does also have secondary benefits such as making testing easier.

Dealing with potential reliability or performance issues with an API leads to some additional considerations. At the very least, the application needs to have timeouts or circuit breakers in place to deal with the unexpected. If circumstances allow, it’s also very beneficial for the application to have a local caching layer to further isolate the user from the API. It’s also essential to design the UI in a way that any problematic situation is clearly understandable to the user. Anything that can go wrong will go wrong, eventually.

It’s lots of work for the application developer to do all of this, but it’s their job. Otherwise, the user might just as well use the original API as-is and the application would thus be worthless. The biggest challenge might be how to know when enough is enough.

API providers serve application developers

It is the API provider’s job to make all of this come true for the application developer, and by extension also for the end user. It will be easy for the application developer to implement an appropriate anti-corruption layer if the API is well designed. The same also goes for dealing with potential reliability and performance issues.

This means that the provider should follow good practices for API design. Calling conventions should follow established patterns. Data should be structured in a logical way with intuitive names. Performance and availability should be sufficient and consistent.

The API should do its thing as expected without causing surprises for the application developer. This in turn makes the API forgettable.

It’s still worth it

All of this sounds like an awful lot of work for everyone involved – except the user who just gets to enjoy a good UI design that works reliably. At the same time, the rewards are immense. That’s why software developers provide and use forgettable APIs despite the efforts involved.

Categories
Uncategorized

AI as a composer:

Using algorithms to compose music in pre-defined styles

With this AIVA – The AI composing emotional soundtrack music
4APIs wish relaxing season time.

Categories
Uncategorized

On API monitoring

Written by Elina Kettunen (UH)

API monitoring is often understood as monitoring the availability, performance, and functional correctness of an API. That is, API monitoring means technical monitoring of  the API behavior during runtime and it covers different measures, such as monitoring how many times an API is called per hour, how fast are the response times, and what is the API resource consumption. API monitoring is a part of API management and, in addition to the basic API monitoring, it is common to add security features, such as audit logs, that aim to answer questions like “who, what, where and when”. 

The goals of web API monitoring can vary depending on the nature of the API. For example, simple, free, information providing APIs mainly wish to keep a record on how many times a single API client contacts the API per hour, as there are limits on how many calls are allowed. Other, more safety critical APIs need a far more comprehensive API monitoring scheme with several different monitoring metrics, monitored resources, alerting policies, and audit logs. 

API uptime monitoring is considered one of the most important monitoring metrics. As the costs of API downtime can be substantial, being able to quickly get notifications on an API being unavailable can be vital for API providers [1, 2]. Also, an API failure can be more catastrophic than an application failure, because a broken API affects potentially multiple applications and users that depend on the API. Thus, there is a need for performance data collection besides usage statistics and API monitors should mimic expected usage scenarios [3]. API monitoring can also cover data validation (i.e. checking if the data the API sends or receives is valid) and Service-Level Agreement (SLA) satisfaction [4].

According to Broadcom’s API monitoring guide, typical DevOps tools, like application performance monitoring tools, may not be able to detect why the API is having a performance issue, and this requires specific API monitoring tools. It is important also to monitor third-party APIs so that issues will be quickly identified and reported to the API producers [4]. 

Often a distinction is made between synthetic and Real-User API monitoring. Synthetic monitoring includes, for example, uptime and performance monitoring, and the API behaviour is analysed by using emulations or simulations for the application environment, scripted tests, API mocks, and service virtualization. Real-User API monitoring covers topics like user experience and transaction performance, and the aim is to use actual users to test the application in real-world environments. This may not be always feasible, but it is especially important for mission-critical APIs [4]. 

From a security perspective, monitoring an API can be used to detect anomalies in user behaviour. If a user starts, for example, accessing certain API operations in a pattern that differs from the usual patterns, it may indicate a potential security issue. If the monitoring system detects such behaviour, it can send an alert to the IT security team [5].

There are several different tools that focus on API monitoring and also tools that provide the whole system for API management. Tech marketplace G2 has a comprehensive list of available API management tools [6], and in their list of the 20 highest rated API management solutions, Postman is at the top. There are also several lists of tools focused on API monitoring available, see e.g. the lists by Comparitech [7] and Nordic APIs [8].

As cloud services are nowadays widely used, service providers like Google Cloud, Amazon Web Services (AWS) and Azure provide many tools for web API monitoring and logging. Often some metrics are free and some available for an extra charge. The cloud service user can pick from a list of available API monitoring metrics those that are the most important for their application. For example, with Azure, the most frequently used metrics are capacity (based on gateway resources like CPU and memory consumption) and requests (number of gateway requests) [9]. In addition to basic API monitoring, the cloud services also provide components for security monitoring and, for example, API access control. As cloud services operate on a pay by usage principle, for example Google Cloud billing alerts can be used to enhance security by monitoring Cloud usage and sending alerts if unexpected consumption is detected [10]. 

Nowadays, APIs are increasingly important for many different types of businesses, and the need for API management and monitoring is growing. With a good API monitoring system and security components, an API provider can monitor API performance and uptime, gain valuable information on the API usage patterns, and detect anomalous calls to the API. There are many tools and solutions available for API monitoring and management, and it seems that more challenging than API monitoring itself is deciding how comprehensive the monitoring should be and understanding the collected data, whether it is about API usage or the content of API calls.

References

[1] https://blogs.gartner.com/andrew-lerner/2014/07/16/the-cost-of-downtime/

[2] https://geekflare.com/api-monitoring-tools/

[3]https://smartbear.com/learn/performance-monitoring/guide-to-api-monitoring/

[4]https://docs.broadcom.com/docs/building-an-api-monitoring-practice

[5] Thielens, J. 2013, “Why APIs are central to a BYOD security strategy”, Network Security, vol. 2013, no. 8, pp. 5-6.

[6] https://www.g2.com/categories/api-management

[7]https://www.comparitech.com/net-admin/best-rest-api-monitoring-tools/

[8] https://nordicapis.com/10-api-monitoring-tools/

[9]https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor

[10] Google Cloud security foundations guide 2020, Google white papers, available at https://cloud.google.com/security/best-practices

Categories
Uncategorized

Digital Platforms and Value Creation

Written by Prashanth Madhala Tampere University

What is a digital platform? A digital platform is a place where producers and consumers exchange information, goods, and services; the digital platform is also a community which brings the above said elements together to co-create value [1]. It allows for participation of and connecting multiple members to it so they can interact, exchange, and create value [2].

To create a successful digital platform, there are key aspects such as use of APIs for connectivity to allow 3rd party members complement the platform with their capabilities, facilitating exchange between the users, trustworthiness & security, usability, ability to scale without affecting the performance in a bad way [1]. Success with digital platform also depends on users (over technologies involved) who are adopting the platform [3]. For example, traditional companies create value within well-defined boundaries, whereas digital platforms co-create value with ecosystem of autonomous participants [4].  Some of the key attributes of a digital platform is that it is a technology-enabled business model, eases communication between several members such as users and producers, value created is proportional to the size of the community, enables trust with regards to data ownership and intellectual property rights, promotes compelling user experience, gives rise to innovative business models [2].

Digital platform has its benefits such as creating new products & services, promotes revenue, enhance profitability and customer experience, operational improvement [5], reduces cost, fosters collaboration and innovation, faster movement of products to the market [2]. Examples of digital platform are social platforms, knowledge platforms, application stores, crowdsourcing platforms, media platforms, infrastructure platforms [2][3].

There are key functions that allow digital platforms to create value. First, the platform must have an audience, the platform must have an audience consisting of consumers and producers facilitating interactions; Second, platform should be able to match consumers and producers for the creation of value; Third, platforms must enable external innovation by the use of APIs in addition to management support; Finally, governance is a very important aspect for governing interactions between all participants [6].

According to [7], in digital service platforms, there are several sources of value created by platform participants; the author provides case study from uber. In the study, an empirical framework is provided which contains three resource combinations namely digital service platform sales, digital service platform safety, digital service platform operation. The sources of value associated with service sales are transaction processing capabilities (tangible, economic value: value-in-use perspective), review and rating system (tangible, intrinsic value: value-in-use perspective), publicity and exploitation (in-tangible, economic value: value-in-use perspective); Second, the safety aspect of the digital service platforms stem from technology reliability (mutual intrinsic value: for e.g. between two participants) and safety (from transparency, intrinsic value); Third, operation of the digital service platforms where the sources of value come from membership (intrinsic value: value-in-exchange), work flexibility (value-in-exchange), rewards and support (economic value: value-in-use). Use value is subjective is defined by the perceived usefulness of the offering, whereas exchange value is recorded when there is a sale between a buyer and seller.

In summary, the term digital platform is defined and understood; digital platforms brings together producers and consumers to co-create value and fosters a community that can continue to co-create value; there are many benefits associated with digital platform such as profitability, innovation, and new business models; for a digital platform to function, there are key attributes and requirements, The sources of value creation is also identified through different types of value such as value-in-use and value-in-exchange.

References

[1]-https://www.bmc.com/blogs/digital-platforms/

[2]-http://stephane-castellani.com/everything-you-need-to-know-about-digital-platforms/

[3]-https://enterprisersproject.com/article/2018/12/what-digital-platform

[4]- Hein, A., Schreieck, M., Riasanow, T., Setzke, D. S., Wiesche, M., Böhm, M., & Krcmar, H. (2020). Digital platform ecosystems. Electronic Markets30(1), 87–98.

[5]- https://xmpro.com/what-is-a-digital-business-platform-and-why-should-i-care/

[6]- https://www.applicoinc.com/blog/how-do-platforms-create-value/

[7]- Mansour, O., & Ghazawneh, A. (2017). Value creation in digital service platforms. In Proceedings of the 28th Australasian Conference on Information Systems, ACIS 2017. Formal Power Series and Algebraic Combinatorics.

Categories
Uncategorized

Notes on REST and GraphQL

Written by Elina Kettunen (UH)

The RESTful web API has been the standard API design architecture, yet during the recent years APIs based on GraphQL Schema Definition Language have gained popularity. In this post the idea is to look into both advantages and disadvantages of REST- and GraphQL-based web APIs. The findings from scientific literature and blog posts are summarised in Tables 1 and 2. 

GraphQL [1] was published by Facebook in 2015, and its key characteristics are support for a hierarchical data model and client-specific queries. The hierarchical data model can reduce the number of endpoints the API clients need to access and the clients can ask only for the data they need [2]. With REST APIs, common problems have been either over-or under-fetching of data; sometimes the client only wishes to show a small part of the available data but the API endpoint provides too much information in the JSON file, and sometimes the client is required to access multiple endpoints to fetch all desired data. Using GraphQL does not necessarily lead to the reduction in the number of queries the API clients need to perform, but it has been shown that in some cases GraphQL can reduce the size of returned JSON documents by over 90% (number of fields and byte size) compared to REST-based APIs [2].

In one study, implementing GraphQL API queries was found to be easier to learn than implementing queries to REST APIs, especially if the query contained multiple parameters [3]. However, implementing a GraphQL server requires certain components such as a GraphQL execution unit, schema and resolvers on the API layer [4], which add complexity and might make using GraphQL overkill for simple applications [5]. Also, with REST APIs, using HTTP caching is easy, but since with GraphQL the idea is to provide a single endpoint for API queries, implementing caching requires extra effort from the developer [2, 5]. 

GraphQL is strongly typed, which means the clients must adhere to data type definitions when making queries, adding to the security of GraphQL [2]. With REST APIs, handling different call types and returned data formats is relatively easy, but file uploading was initially not supported by GraphQL and support for file upload requires installing a library [6]. Since client applications are able to see all fields in GraphQL, information hiding is not well supported [2].

Large, complex nested queries are a potential performance and security problem for GraphQL servers, since processing large queries requires considerable effort and may lead to denial of service if the server cannot cope with the requests. Limiting the query complexity and depth is therefore necessary [7]. 

As a still emerging technology, GraphQL does not have as much tool support as REST APIs. The lack of monitoring tools has been mentioned in one blog post [8]. GraphQL has also lacked means for integrating multiple interfaces that are important in distributed systems. A solution to this problem is to use GraphQL Federations, which are common interfaces used on top of existing GraphQL web service interfaces. Besides an existing solution (Apollo Federation [9]) researchers have also proposed a novel framework to address the multiple interface integration problem [10]. 

REST APIs are generally considered simple and inexpensive with good interoperability, flexibility, scalability and robustness. GraphQL provides great flexibility on the frontend as changes in data usage usually need not to affect the server. GraphQL and REST do not need to be alternatives to each other as they can be used in parallel. GraphQL is well suited for example API gateways [4]. There are several GraphQL engines that support major programming languages and different query planning tools can translate GraphQL queries into other query languages [11]. Also, deprecating fields is easy and adding new fields to a type does not lead to breaking changes in GraphQL APIs, which makes versioning easier [2]. With GraphQL, API developers can avoid over- and under-fetching issues, and gain performance benefits by reducing the overhead from transferring large JSON files.

Table 1. Advantages and disadvantages of REST API design architecture.

Table 2. Advantages and disadvantages of GraphQL design API architecture.

References

[1] https://graphql.org/

[2] Brito, G., Mombach, T. & Valente, M.T. 2019, “Migrating to GraphQL: A Practical Assessment”, SANER 2019 – Proceedings of the 2019 IEEE 26th International Conference on Software Analysis, Evolution, and Reengineering, pp. 140-150. 

[3] Brito, G. & Valente, M.T. 2020, “REST vs GraphQL: A controlled experiment”, Proceedings – IEEE 17th International Conference on Software Architecture, ICSA 2020, pp. 81-91. 

[4] Vogel, M., Weber, S. & Zirpins, C. 2018, Experiences on Migrating RESTful Web Services to GraphQL. In: International Conference on Service-Oriented Computing. Springer, Cham, 2017. p. 283-295.

[5] https://medium.com/@back4apps/graphql-vs-rest-62a3d6c2021d

[6] https://levelup.gitconnected.com/how-to-add-file-upload-to-your-graphql-api-34d51e341f38

[7] Wittern, E., Cha, A., Davis, J.C., Baudart, G. & Mandel, L. 2019, An Empirical Study of GraphQL Schemas. In: International Conference on Service-Oriented Computing. Springer, Cham, 2019. p. 3-19.

[8] https://www.moesif.com/blog/technical/graphql/REST-vs-GraphQL-APIs-the-good-the-bad-the-ugly/

[9] https://www.apollographql.com/docs/federation/