[Part 2] REST API components & How to read them 👻

[Part 2] REST API components & How to read them 👻

Happy Halloween! 🎃 Every month I share a Tech Term You Should Know (TTYSK) 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 Rate Limiting (after essay) and the essay is REST API components & How to read them.

As a PM, you'll most likely encounter Rate Limiting if you work on a high traffic, high scale product and know it's a possible cause of sudden and acute API errors.

REST APIs are an essential part of your technical education and you'll encounter them in all areas including while on-the-job, during technical discussions, interviews, etc.

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.

Connect with me on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.

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 2] REST API components & How to read them

Ask me anything & I'll answer it in an upcoming issue.

If you missed Part 1 of this 3 part "Guide to APIs" series, check it out here.

In Part 1, you learned about API communication protocols and 3 of the most commonly used ones: REST, SOAP, and GraphQL.

In Part 2, we’re going to get real close and intimate with REST APIs specifically.

Why? Because REST APIs are the most prevalent and user-friendly type of APIs that you’re most likely encounter. As a product manager, you play a pivotal role in working with your engineering team to bring digital solutions to life, and a fundamental part of that collaboration is understanding REST APIs.

So in this essay, you’ll get a break down of REST APIs into their essential components so you can confidently discuss, dissect, interact with, and debug them.

Brief intro to REST APIs

Recall in part 1 that APIs allow two applications to communicate with each other.

REST APIs are a set of rules and conventions that defines a standardized way for requests and responses to be structured and exchanged. It is based on the principles of REST, which is a software architectural style for designing networked applications. You’ll also hear the term RESTful APIs in relation to REST APIs.

Here are a couple examples of RESTful rules and conventions followed by REST APIs (not important to memorize, just to give you an idea of what these rules look like):

  1. Client-server: Separation of concerns whereby the user interface concerns (client) are separate from the data storage concerns (server).
  2. Stateless: Each request from the client to the server must contain all of the information necessary to understand and complete the request. The server cannot use previously stored context information on the server.

REST APIs make extensive use of HTTP (Hypertext Transfer Protocol) as the foundation for communication between clients (like web browsers or mobile apps) and servers (where the API is hosted). 

The majority of what you need to know about APIs are related to HTTP and it’s components. We can broadly bucket the components into the API Request and API Response:

Components of API Request and API Response

API Request

When you make a request to an API, you’re essentially saying, “I want to do something or get something from this endpoint.” Requests consist of the following components:

  1. Endpoint
  2. HTTP Method
  3. Request Headers
  4. Request body

1/ API Endpoint

An endpoint is the specific location aka the access point to the API. Think of it as an address for a particular service or resource. These endpoints are usually represented as URLs (Uniform Resource Locators), making them easy to understand. The API endpoint is made up of the “ Base URL” plus the “path” of the API.

2/ HTTP Methods

HTTP (Hypertext Transfer Protocol) methods are the actions you can take when interacting with an API. There are 8 request types but 4 are the most commonly used:

  • GET: This method is like asking for information. When you send a GET request to an API’s endpoint, you’re requesting data, like retrieving weather information for a specific location.
  • POST: When you send a POST request, you’re submitting data to the API which adds new data to the database. This could be creating a new user account or adding a comment on a blog post.
  • PUT: Use the PUT method to update existing data. For instance, you might change your profile picture on a social media app.
  • DELETE: As the name suggests, the DELETE method is for removing data. If you want to delete a post or an account, you’d use this method.

You’ll likely see all 4 HTTP methods being used at some point, but out of the 4, you’ll see the GET and POST method most frequently and those are the two that you should be most familiar with.

Two quick side notes:

The POST and PUT methods are often used interchangeably. The difference has to do with something called idempotency which is very technical in nature and really not worth diving into if you’re just getting started with APIs, but feel free to read about idempotency here if you’re curious.
You’ll also see the same POST API sometimes used to both add new data and update existing data. Developers may decide to design the API this way to be more efficient as opposed to creating and managing two separate APIs in the business logic: one POST and the other PUT.

3/ Request Headers

Request headers convey additional information about the API request, such as the format in which the client expects the response (e.g., JSON or XML), authentication credentials, caching instructions, and more.

Here’s an example using Amazon:

Information in the request header can be used for a number of reasons including:

  • Authenticating the request: There are various authentication methods, such as API keys, OAuth tokens, and username/password combinations. For example, credentials for your bank account so the API is authorized to make changes to your account.
  • Caching instructions: Temporarily storing data in a cache for improved future performance/latency.
  • Logging: All systems keep a log of events that occur in a computer system. Information stored in the headers (i.e. location of request origin, browser information, date & time of request, etc..) are logged in log files. The information in the log files can then be used for a variety of reasons: debugging, metrics, and telemetry.Accept-Language: en-US
    Authorization: Bearer YourAccessTokenHere

4/ Request Body

When you need to send data to the server, you include it in the request body. The data is typically in a structured format like JSON or XML. This is common when creating new records or updating existing ones. The request body is akin to a letter with the information you want to submit.

For example: Amazon has an internal API that adds a new product into the database.

API Response

Once you send a API request, you’ll receive an API response. This response contains the data or information you requested, as well as metadata about the response itself. It consists of the following components:

  1. Status Code
  2. Response Headers
  3. Response Body

1/ Status Code

This is a three-digit number that tells you the outcome of your request. Status codes are like short, standardized messages that quickly convey whether your request was successful, encountered an issue, or faced an error. All status codes are divided into 5 categories but you’ll only really encounter 4 of them:

  • 2xx: Success — The API request was successful! e.g. 200 OK, 201 Created
  • 3xx: Redirection — The API request has more than one response. e.g. 301 Moved Permanently, 302 Found
  • 4xx: Client Error — Some information provided in the request was wrong or missing. e.g. 400 Bad Request, 401 Unauthorized
  • 5xx: Server Error — Something went wrong on the server and the request wasn’t successful. e.g. 501 Internal Server Erorr, 502 Bad Gateway

Here are some examples of common status codes:

  • 200 OK: Your request was successful, and you’ll find the data you wanted in the response.
  • 201 Created: This code typically appears after a successful POST request, indicating that the resource you requested has been created.
  • 400 Bad Request: If the API couldn’t understand your request, you might see this code.
  • 401 Unauthorized: When you lack proper authorization or credentials to access the requested data, this code appears.
  • 404 Not Found: This indicates that the endpoint or resource you’re looking for doesn’t exist.
  • 500 Internal Server Error: If something goes wrong on the other island (the API’s server), you might see this code.
Common API status codes

2/ Response Headers

Similar to request headers, response headers provide additional information about the response, such as the type of data you’re receiving (e.g., JSON or XML), the server’s version, and more.

Here’s an example also using Amazon:

3/ Response Body

This is where you’ll find the actual data or information you requested. Like the request body, the response body is often in JSON format for easy readability and parsing.

Using the same Amazon API example as the one in the request body, here’s what a successful response where the product was successfully added to the database might look like. Notice the API response returned a newly created product_id uniquely assigned to the added product.


We’ve covered the crucial parts of the API and you now have all the information you need to confidently discuss, dissect, interact with, and debug APIs.


In Part 3 of this API guide, we’re going to apply your new found knowledge into practical use. We’re going to look at a couple of real-life scenarios where you’ll need to apply your API knowledge as a product manager and you’ll learn how to debug errors based on API responses.

So don’t miss Part 3 and subscribe!

October's Tech Term You Should Know (TTYSK)

API Rate Limiting

Rate limiting is a common networking technique used throughout the internet. In the context of APIs, rate limiting is a mechanism that controls and restricts the number of requests or actions a user or application can make within a specified timeframe.

For example, X (formerly Twitter) imposes rate limits on its API to prevent abuse and ensure fair usage and their rate limits are as follows:

  1. User Timeline API: 900 requests per 15-minute window.
  2. Search API: 180 requests per 15-minute window.
  3. Streaming API: Limited based on connection type and use case.

API rate limiting is used for many reasons, but the 2 main ones are security and cost control:

1/ Security: They help protect against distributed denial of service (DDoS) attacks, where a malicious entity/hackers flood the API with requests to try and bring down the server. (If you want to learn more about DDoS attacks, check out this essay I wrote.)

2/ Cost Control: They can also serve as a cost-control mechanism since API usage isn't free and excessive usage can get expensive quickly.

Many cloud services like AWS API Gateway, NGINX, Redis, CloudFlare, and Fastly offer API rate limiting capabilities. It's also possible to build your own rate limiting solution using programming languages like Python or middleware like Express.js for Node.js.

Ex: How API rate limiter works
What to know about API Rate Limiting as a PM:
As a product manager, you will most likely only happen upon rate limits when errors occur when the rate limit is reached. When this happens, devs will discuss what the next steps are (increase limit and/or determine the cause and source of high traffic of requests).

It's also possible that your app will need to follow certain rules in order to accommodate the API rate limit and this affects the app features which ultimately affects the customer experience. In this case, you'll be able to work with your dev team on what the technical requirements are that will affect the business requirements.

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.

Thanks! This was super useful! Meh. Could be better. Not useful or interesting.

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.

As always, connect with me on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.