Every month I share a Tech Term You Should Know (TTYSK) and an essay to level up your technical chops and get the most out of dev teams. Ask me anything and I'll cover it in an upcoming newsletter issue.
This issue's TTYSK is HTTP and the essay is 3 API Protocols you need to know.
Dev teams spend a large chunk of time designing and building APIs so it’s crucial you’re able to fully engage during technical discussions about them.
In this 3-part “Guide to APIs” series, I’ll walk you through the most critical API knowledge. We won’t go deep into implementation—just deep enough for you to be dangerous.
- [Part 1] 3 API protocols you need to know
- [Part 2] REST API components & How to read them
- [Part 3] PM Best Practices for Debugging APIs
Want technical training for your Product team?
Become more technical in just 5 weeks, without learning to code. Find out if Skiplevel is the right fit for your team at skiplevel.co/teams.
[Part 1] The 3 API Protocols you need to know
Ever heard of RESTful APIs or GraphQL?
If you’ve worked in the tech industry for a while, it’s likely you have. But before we jump into what they are, let’s briefly touch on APIs.
APIs are the ultimate communicators of the internet and they allow two applications to communicate with each other.
APIs are all around us. Every time you use a rideshare app, pay off a credit card balance, or send a DM on your social media platform of choice, etc. To get an idea of how ubiquitous APIs have become, check out this cool graphic on API usage in 2020:
APIs do not generally impact user experience (although they can if performance hinders them). Instead, APIs impact developer experience — how easy it is to connect and integrate with another system.
Anything that impacts developer experience potentially impacts the product roadmap, so the more you know about them the more prepared you’ll be during technical discussions.
Not all APIs are built the same way — they’re built around what are called communication protocols and there are a few of them.
API protocols are like the universal translators of the digital world. They are a set of rules and conventions that let different software applications talk to each other in order to share data and functionality. Imagine you have two friends who speak different languages, and you want to help them communicate. API protocols are like to the translator who bridges the gap between them.
These protocols dictate how information should be structured and exchanged, so that when one app sends a message or API request, the other app understands it perfectly.
Think of it as a standardized menu in a restaurant; you know what to expect when you order a “hamburger” or “spaghetti” and the waiter knows exactly what you’re asking for. The menu is what helps you and the waiter communicate.
There are various types of API protocols but the most widely-used are the following 3: REST, SOAP, and GraphQL.
Quick note: APIs can support communication with APIs of different protocols (though engineers need to write code to support multiple protocols). Email Servers, for instance, supports requests from APIs using the REST and SOAP protocol. The Google Maps API also provides a comprehensive web service that supports multiple types of interaction and connectivity.
REST: Representational State Transfer
REST APIs are everywhere in modern web and mobile applications, which means most of the APIs you’ll come in contact with, and likely your engineers are building will be REST APIs a.k.a. RESTful APIs.
REST APIs have become the de facto standard for building web services and enabling efficient communication between software systems due to their simplicity and scalability.
REST APIs uses JSON for its data format and the HTTP/HTTPS methods to interact with resources and transmit data from one application to another. REST APIs are more flexible than SOAP APIs (see below section on SOAP), but are also limited in its transmission types.
Here are the components of a REST API call:
- HTTP method (POST, GET, PUT, DELETE): the action that the API is taking (i.e. retrieving data, updating data, creating new data, etc..)
- Endpoint (URL): the location the data is being sent to and where the API is accessed.
- Header: data about the data (such as the origination server).
- Body: the information actually held within the transmission.
For instance, when you submit a contact form on a website, your browser is making a REST API request to a server with the data you submitted. Anytime you create a new post on a social media platform (i.e. Twitter, Facebook, Instagram), a REST API is made to a remote server to store the data in the database and once successful, your feed will update.
GraphQL is the newest type of API protocol to enter the field as it’s become popular within the last 10 years. GraphQL was developed by Facebook in 2012 but later open-sourced in 2015, gaining popularity for its flexibility and efficiency. They’re a modern approach to requesting and delivering data between software applications.
Unlike REST APIs, where clients receive a fixed set of data from predefined endpoints, GraphQL APIs allow clients to request precisely the data they need and nothing more. This precision is more performance as less data is being transferred across the wire.
A GraphQL API consists of three main components:
- Query: This is the client’s request for specific data. Clients can specify the exact fields they want, which helps reduce over-fetching of data.
- Schema: The schema defines the structure of the data available through the API, including the types of data and the relationships between them. It serves as a contract between the client and server.
- Resolver: Resolvers are responsible for fetching the requested data. They determine how to retrieve and format the data based on the client’s query.
Compared to REST and SOAP APIs, GraphQL APIs offer more control to clients and reduce the problem of over-fetching or under-fetching data. They have gained popularity, especially in modern web and mobile app development, where fine-grained control over data retrieval is crucial for performance and user experience.
GraphQL APIs are typically used in scenarios where customization and efficiency are important, such as social media platforms, e-commerce websites, and applications with complex data requirements. They enable developers to build more responsive and optimized applications by allowing clients to request only the data they need, resulting in faster load times and improved user experiences.
As a result, GraphQL has become a popular choice for many developers seeking a more flexible and efficient way to interact with APIs.
SOAP: Simple Object Access Protocol
Before REST APIs, SOAP APIs were the communication protocol of choice having been around since the late 1990s. They were once super popular, particularly with enterprise-level applications where secure and structured data exchange was critical.
But SOAP APIs have seen a decline in recent years, as simpler and more lightweight alternatives like REST APIs gained traction. REST’s simplicity made it more attractive for web and mobile app development. However, SOAP is still relevant, especially in scenarios where data integrity and security are paramount, such as financial transactions and healthcare systems. It’s also commonly used in enterprise applications that require standardized communication.
SOAP uses XML as its format for data exchange. It consists of several key components:
- Envelope: This is like the outermost wrapper, which defines the start and end of the message.
- Header: This is optional and contains metadata about the message, such as authentication or routing details.
- Body: The heart of the message, where the actual data resides.
- Fault: Also optional, it contains information about any errors that may have occurred during the message exchange.
In summary, SOAP APIs have a history of being widely used for their structured and secure communication, although they have become less popular compared to REST APIs, which are simpler and more adaptable for modern application development. SOAP APIs are still prevalent in specific domains where data integrity and reliability are crucial.
There are a number of communication protocols out there but SOAP, REST and GraphQL are the most widely used. It’s not important to memorize the technical details of each. It’s more important to have a broad landscape understanding of the types of APIs so you know what’s being discussed and can do an appropriate search engine query (or refer back to this essay) if additional detail is required.
Here’s a quick graphic comparison of the 3 API protocols:
This month's Tech Term You Should Know :
HTTP (Hypertext Transfer Protocol) is the foundation of data communication on the internet. It's a set of rules that defines how messages (or data) are formatted and transmitted between web servers (server) and web browsers (client).
When you type a URL into your browser and hit "Enter," your browser initiates an HTTP request to the web server hosting that website. This request asks for a specific resource, like a web page. The web server then processes this request and responds with an HTTP response, which includes the requested data, like the web page's content.
HTTP uses a client-server model, where the browser is the client, and the server is where websites are hosted. It's like a structured conversation between your browser and the server, ensuring information is requested and delivered accurately.
What to know about HTTP as a PM:
You're already familiar with HTTP by browsing the internet; notice the http:// or https:// at the beginning of every URL. That represents the HTTP protocol being used whenever you open a website.
But what's most important to understand about HTTP is its use of the
client-server model. This model of communication underscores how data is communicated across technology and software. Let's break it down simply:
(1) Client: Anything that initiates requests for services or resources from another device or program. Typically end-user devices like computers, smartphones, tablets, or a browser (Chrome, Safari, Edge, etc). Their 3 main jobs are to make requests, receive responses, and present the requested information to the user in a human-readable format.
(2) Server: A device, application, or program that listens for and responds to incoming requests from clients. Typically more powerful and specialized than clients and designed to handle multiple incoming requests simultaneously. Servers process incoming requests, perform the necessary tasks to fulfill those requests, and send back responses to the requesting clients.
This is what HTTP communication looks like between the Client and Server (known as a HTTP request/response):
I need your help! How can I improve this newsletter?
I put in a lot of time and effort providing you with the best technical literacy content, and I need your help. Tell me how I can improve this newsletter.
Missed the mid-month PM & Tech Jobs Newsletter?
Looking for a new job? Our PM & Tech Jobs newsletter is issued monthly with product role job listings from senior to entry-level roles.