APIs are everywhere and used for various purposes. When we’re talking about APIs, we’re typically referring to web APIs.

In a typical client-server interaction, the client sends a request to the server and the server returns a response.

Let's take a practical example. You want to know where the nearest pharmacy is, so you initiate a Google search with 'pharmacies near me', in a clear language that the receiver can understand. When you hit the search button, the browser (client) will send your request to a server. The server, which has some data already stored in its database, will take your input and search the existing database. A database is an organized collection of structured information, or data, stored electronically in a computer system. In a few milliseconds, the server will send a reply with the desired result.

Photo by Douglas Lopes on Unsplash

Types of APIs

Typically APIs can be segmented by availability, aka release policies, or by use cases according to the systems for which they are designed.

By use cases, APIs can be database, operating systems, remote or web APIs. The most common pair of web systems is a web client and a server. Web APIs facilitate the exchange of formatted queries between clients like web browsers or mobile applications and servers. These APIs mainly deliver requests from web applications and responses from servers using Hypertext Transfer Protocol (HTTP).

Nowadays, most application programming interfaces are web APIs that expose an application's data and functionality over the internet.

In terms of release policies, APIs can be private, partner, and public. Public can further be open public or commercial public APIs. Here are the main types of web APIs:

• Private APIs are application programming interfaces primarily used by employees within an organisation. Internal APIs are hidden from external users and aren't available for users outside of the company.

  By restricting the interface availability to those working directly with the API publisher, a company can leverage existing systems and fully control the API usage. The core goal with these application programming interfaces is to improve productivity, communication, solutions and services across different internal development teams within the organization.

• Partner APIs are application programming interfaces shared to or by strategic business partners who have signed an agreement with the publisher. Typically, developers can access these APIs in self-service mode through a public API developer portal as they are openly promoted.

  The common use case for partner APIs is software integration between two parties. A company that grants partners with access to data or capability benefits from extra revenue streams. At the same time, it can monitor how the exposed digital assets are used, ensure whether third-party solutions using their APIs provide decent user experience, and maintain corporate identity in their apps.

• Public APIs are available for any third-party developers. A public API, also known as developer-facing or external, allows for increasing brand awareness.

  There are two types of public APIs – open (free of charge) and commercial APIs. Commercial API users pay subscription fees or use APIs on a pay-as-you-go basis.

  Open APIs are open source application programming interfaces you can access with the HTTP protocol and can be used freely without restrictive terms and conditions, explicit approval from the API supplier or mandatory licensing fees. The API description and any related documentation are openly available, and the API can be utilized to build and test applications.

• Composite APIs combine multiple data or service APIs. These services allow developers to access several endpoints in a single call. Composite APIs are useful in microservices architecture where performing a single task may require information from several sources.

Understanding the web-based APIs as a Beginner

Let’s discuss major API styles in and highlight the scenarios where each of them fits best.

As the use of web APIs has increased, APIs facilitate standardized information exchange:

• SOAP (Simple Object Access Protocol) is a lightweight API protocol built with Extensible markup language (XML). SOAP uses XML technologies to define an extensible messaging framework. XML is a simple and very flexible text format widely used for data storage and exchange in a self-descriptive format which makes them easily readable.

  This protocol enables users to send and receive data between systems through HTTP or Simple Mail Transfer Protocol (SMTP). With SOAP APIs, it is easier to share request and response messages between apps or software components.

  SOAP is mostly used with enterprise web-based software to ensure high security of transmitted data. Some developers find SOAP APIs difficult to use because it requires following the XML structure for every message sent and writing a lot of code to complete every task.

  SOAP APIs are preferred among providers of payment gateways, identity management and CRM solutions, as well as financial and telecommunication services. It’s also frequently used for legacy system support.

• REST (Representational State Transfer) is considered a simpler alternative to SOAP. Unlike SOAP, REST is a software architectural style with set of web API architecture principles, not a protocol. This means there are no official standards to be a REST API (also known as a RESTful API). The term REST was introduced by Roy Fielding, computer scientist, in a dissertation [external link] in 2000.

  RESTful architecture should comply with six architectural constraints for building applications that work over HTTP.

  • uniform interface
  • stateless
  • caching
  • client-server architecture
  • layered system of the application
  • the ability for servers to provide executable code to the client

• GraphQL-based APIs is a query language for APIs. GraphQL was initially created by Facebook in 2012 for internal use. GraphQL allows the client to detail the exact data it needs and simplifies data aggregation from multiple sources, so the developer can use one API call to request all needed data. GraphQL uses a type system to describe data.

  Apps using GraphQL control what data they need to fetch from a server, which allows them to run fast even when the mobile connection is slow.

• XML-RPC is a protocol that relies on a specific format of XML to transfer data, whereas SOAP uses a proprietary XML format. XML-RPC is older than SOAP, but much simpler, and relatively lightweight in that it uses minimum bandwidth.

• JSON-RPC is a protocol similar to XML-RPC, as they are both remote procedure calls (RPCs), but this one uses JSON instead of XML format to transfer data. Both protocols are simple. While calls may contain multiple parameters, they only expect one result.

Voila! That’s it for understanding API as a beginner. Next up, I will incorporate more no-code and startup founder lessons for a more holistic understanding of this blog.

Until next time.

ABOUT ME

I'm Juliet 'Hiri' Edjere, a no-code expert focused on design, business development, and building scalable solutions with minimal coding knowledge.

I document all things product stories, MVP validation, and how designs, data, and market trends connect to one another.

In our world where innovation knows no boundaries, and creativity reigns supreme, no-code is a game-changer in today's tech landscape. Whether you're a developer looking to expand your skill set or a beginner curious about creating without writing a single line of code, you will learn from practical examples, and explore the possibilities of no-code technology. Together, we'll navigate the tools, platforms, and strategies – one blog post at a time!

Visit my website →