Originally posted: Aug, 2026
This time we will try to explain and simplify three different elements of technology that have been around for the past few years, with GraphQL being the newest.
We will start this new series of articles in the following order APIs –> REST APIs –> GraphQL. We could even go back to SOAP APIs, but that would confuse us more (like it did with me), which is precisely what we are trying to avoid.
This was the best way I could understand some of these concepts, and I will likely keep on learning as this is vast.
We will continue creating more derivations of these three elements as they touch on multiple engineering and software development areas. Some definitions and usages relate to each other, while others are meant to create clear separation and bring clarity (i.e., Rest API vs. GraphQL).
Those three letters have been more common to hear in our daily IT working lives: Application Programming Interfaces or API for short, but we always seem confused with words like endpoints, links, connections, or simply an application connecting to another (which in essence that is the end goal). No one to blame; it merely highlights the fast-track technology has made us part of.
So, let’s start with API’s more formal/structured definition. An API is a set of methods, functions, or other operations which can be called from within a software application to exchange information with another software application. It is like an online manual – it allows to call functions, call other parts or get data from another system.
APIs are used extensively in many applications such as website integrations (Facebook, Twitter, etc.),
A public API is usually published on a website and only requires registration to access it. It is a powerful tool for developers and allows them to integrate real-time data from multiple sources into their applications.
Some APIs are made publicly available by the vendor, while some are private, as we said before.
A private API is not published and can only be used within the same software application. It does not require registering to use it but is limited in its functionality. For example, it might only allow access to a limited function set or only allow access if a specific type of data is included (such as a login) or even user restrictions.
To make it more explicit, a privately exposed API allows a developer to access parts of an application’s functionality to validate a credit card number without exposing the entire application to security risks; say we want customer services to validate the information without actually seeing the complete credit card number, security code, or any personal information that might harm the customer should it end in the wrong hands.
A hybrid API is an interface that can be either public or private at the developer’s discretion.
We really don’t care If they are private, public, or hybrid, but it is good to know that there are more than just public APIs, as this is the most common version we hear out there.
To start bringing this down to relatable terms, imagine you go to any retail store and can’t find the right-size shirt you are looking for. Think about your next step. What would you do? If you answered, look for someone to look at their inventory in the back, then you are thinking like a user of any API out there. You would look for a retail store agent and ask if they can check in their inventory for the desired size; the person would look and come back with an answer; that is precisely what APIs will do.
In API world, a person creating an application that requires the usage of another application/system to validate a user’s request will most likely have an API (or many) in the middle.
So, imagine you want to sign-up for the newest and hottest social media platform and subscribe via your email address. To do this, the developer must create an API connection to that email provider and validate this information.
The developer creating/programming an API in this scenario would need to: create an API connection (you can read more about API keys here), create the online forms for the user to sign via email, and the developer’s code will interact with the social media application, return the validation of the provided email address, and exchange information to enroll the user with the email address. Notice how the user tries to access the social media platform with the email address, not the email provider itself. The developer doesn’t know, nor does he need to know, how information flows internally at Gmail, iCloud, etc.; they only need that email address to be validated and have the user sign in to continue with the enrollment process.
I hope this simple explanation provides the path for you to keep exploring; there are many more articles and videos out there where you can get detailed information. Keep on searching and never stop learning.
Next up: REST APIs.
Reference Links
https://www.helpsquare.net/blog/difference-between-public-apis-and-private-apis-an-insiders-guide/
Lawgorithm 
Enjoy the reading