Evolution of API Protocols/Styles
The abstract idea behind Application Programming Interface (API) which helps to communicate with other systems or applications came in to existence since early days of programming.
The concept of setting up rules to make the inter communication between software systems feasible and effective lead to old intercommunication protocols like RPC, CORBA.
As the software domain grew into a bigger dimension with innumerable challenges and demands, several new communication protocols evolved. This gradual evolution in inter communication between software systems lead to the wide spread use of APIs.
API use has increased over the past years, that several most popular web applications today would not be possible without APIs.
1. Remote Procedure Call (RPC)
A remote procedure call (RPC) was implemented in 1981. It was introduced as a procedure to execute in a different computer on a shared network as if it were a local procedure call, without developer specifically coding the details for the remote interaction.
When a remote procedure is invoked, the calling environment is suspended, the parameters are passed across the network to the environment where the procedure is to execute and the desired procedure is executed there. When the procedure finishes and produces its results, the results are passed backed to the calling environment, where execution resumes as if returning from a simple single-machine call. While the calling environment is suspended, other processes on that machine may still execute (depending on the details of the parallelism of that environment and the RPC implementation) [1].
Disadvantage of RPC was tight coupling with client and server. RPC allows designers to build distributed systems but does not solve many of the problems distribution creates. So, it is only considered as a low-level construct.
2. Common Object Request Broker Architecture (CORBA)
CORBA released in 1991 as a standard, for remotely calling operations on distributed objects across networks. CORBA’s benefits include OS and language independence, freedom from technology-linked implementations, high level of tunability, strong data-typing and freedom from the details of distributed data transfers.
Reasons of the failure of the CORBA standard were due to the process by which the CORBA specification was created. The compromises made by several competing implementors in writing common standard, due to politics and business lead to its failure.
3. Simple Object Access Protocol (SOAP)
SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It was initially released in 1998.
SOAP defines a messaging envelope structure designed to carry application payload in one portion of the envelope (the message body) and control information in another (the message header).[2] SOAP allows developers to invoke processes running on different operating systems to authenticate, authorize, and communicate using Extensible Markup Language (XML).
Since Web protocols like HTTP are installed and running on all operating systems, SOAP allows clients to invoke web services and receive responses independent of language and platforms. SOAP also became underlying layer for SOAP based webservices which make use of Web Services Description Language (WSDL), XML schema and Universal Description Discovery and Integration (UDDI).
SOAP uses tight coupling between the client and server. Since it uses XML format, SOAP is considered to be a slow platform because the payload is large for a simple string message.
4. REpresentational State Transfer (REST)
REST is a software architectural style created to guide the design and development of the architecture of the World Wide Web. Representational state transfer concept was introduced in 2000 by Roy Fielding in his doctoral dissertation.
REST is accepted set of guidelines to create reliable, stateless web APIs. REST uses a resource identifier to identify the particular resource involved in an interaction between components [3]. Clients can only access resources using URIs. The client requests a resource using a URI and the server responds with a representation of the resource. Clients can also modify items on the server and even add new items to the server through a REST API.
In REST the coupling between the client and the origin server will be lightweight (loose) as possible to enable large-scale adoption. REST is not a standard in itself, but REST implementations make use of standards, such as HTTP, URI, JSON, and XML. Numerous popular web and cloud companies implement REST APIs for their applications, including YouTube, Twitter, and Google.
5. GraphQL
GraphQL was developed by Facebook in 2012 for internal projects before publicly released in 2015. The GraphQL Foundation, a newly established organization hosted by the Linux Foundation governs developments around GraphQL. GraphQL is an open-source query language and the protocol for APIs.
A GraphQL query is a string that is sent to a server to be interpreted and fulfilled, which then returns JSON back to the client [4]. It is the modern alternative for REST-based architecture. GraphQL runtime are being built in various languages, including Go, Ruby, Scala, Java, .Net, and Python. Tools like GraphiQL, an in-browser IDE, documentation browser, and query runner are available [4].
Unlike REST, GraphQL allows flexibility for client to request specific data that a client needs, avoids fetching excess information from server. It reduces overhead of multiple round trips to fetch data from server to render a front-end view.
GraphQL is apt for building mobile cross platform applications. REST API requires changes to the API endpoints every time the frontend changes. Such frequent changes to the backend impact the ability of the development team to change the frontend, and this reduces the productivity.
GraphQL solves this issue by providing developers the flexibility to write queries specifying their data requirements. Thus, iterations for developing of the front–end can continue without having to change the backend.
REST vs GraphQL- Which is better?
Currently plenty of discussions going on around the future of API development, will GraphQL APIs replace REST and which API style will handle the upcoming challenges of API development space. Both REST and GraphQL are efficient ways to design APIs and how applications can access data from it.
REST simplified the work of developers with its standardised design concept, nevertheless it has some drawbacks. GraphQL, with its queries and schemas offer much desired flexibility for developers.
But we cannot say GraphQL can entirely substitute REST since GraphQL is a tool, whereas REST is an architectural pattern. Which one will be a better fit for a project will depend on unique user scenarios and requirements in projects. Proper analysis of your application, data, performance requirements and platform requirements is needed to decide on API style appropriately.
API Infrastructure Layer of Paysack
Our Paysack API platform employ advantages of both REST and GraphQL APIs.
Read more: What is the Paysack Fintech Platform?
Paysack API platform offers reliable APIs for the FinTech domain ranging from Card management to Investment and Closed loop payments. We help companies to go from ideas to launch, as a trusted partner from day zero.
This helps you focus on building the core business and leaving all the technology management challenges to us.
Get started with the Paysack API Platform here: https://platform.paysack.com/
References
1. Birrell, Andrew D.; Nelson, Bruce Jay (1984). “Implementing remote procedure calls” (PDF). ACM Transactions on Computer Systems. 2: 3959. doi:10.1145/2080.357392
2. Hirsch, Frederick; Kemp, John; Ilkka, Jani (2007-01-11). Mobile Web Services: Architecture and Implementation. John Wiley & Sons (published 2007). p. 27. ISBN 9780470032596.
3. Fielding, Roy Thomas (2000). “Chapter 5: Representational State Transfer (REST)”. Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine
4. https://graphql.org/blog/graphql-a-query-language/