Anatomy of an API request

Introduction

In today's modern world, the significance of APIs cannot be overstated. In previous articles on this series API101: A Beginner's Guide to Application Programming Interfaces Part One and Part Two, we explored the immense importance of APIs, ranging from their ability to modularize software and promote code reusability to facilitating seamless system integration, enabling efficient service access, and encouraging third-party integrations and client-server communications.

Building upon the foundation laid in the introductory article, this next piece aims to delve deeper into the core of API functionality. Specifically, we will thoroughly dissect the structure of an API request, shedding light on its constituent elements and their significance. By understanding the intricacies of an API request, developers and enthusiasts alike can grasp the underlying mechanics that power modern web development and foster effective communication between systems.

Throughout this article, we will unravel the anatomy of an API request, demystifying its composition and exploring key components such as endpoints, HTTP methods, headers, query parameters, and the request body. By comprehending the structure of an API request, you'll gain a comprehensive understanding of how to interact with APIs effectively, enabling you to harness their power to build robust and interconnected applications.

Join me on this enlightening journey as we navigate the fascinating realm of API requests, unveiling the underlying framework that drives seamless data exchange and empowers the software development landscape.

What is an API Request?

Building upon the concept of client-server communication, API requests serve as the vital link that initiates the interaction between the client and the server. In essence, API requests act as messengers, carrying specific messages or instructions from the client to the server. They play a pivotal role in enabling seamless communication and resource sharing between the two entities, empowering developers to harness the power of APIs in their applications. There are various components to the API request that make a request to a server possible:

  • API Endpoint

  • HTTP Methods

  • Request Headers

  • Query Parameters

These four components are what make a request to a server possible. Some of these components can be omitted. But the two most important components that are present in any API request are the API endpoint and the HTTP headers.

An example of an event that gives an analogy of what an API request is and what it does is a student going to a library and asking for a book.

The library is the API server. The book is the resource that you want to access. The librarian is the API. The request is you asking for the book. The response is the librarian giving you the book.

Understanding Endpoints

Source: PrivateTech

An endpoint refers to a designated location on a server where a client can make a request. It is essentially a URL that specifies the specific location of a particular resource.

For instance, consider the URL https://codedaddy.hashnode.dev, which retrieves all the blog posts authored by a particular individual. This URL serves as the endpoint, indicating the exact location of the desired resource. To draw an analogy, the URL can be likened to the address of a library, providing the specific location where the books (resources) can be accessed.

Some popular endpoints or URLs include:

- https://twitter.com/@nwokporo_ebuka
- https://medium.com/@nwokporochukwuebuka
- https://linkedin.com/in/chukwuebuka-nwokporo/
- https://github.com/nwokporochukwuebuka

HTTP Methods

Understanding the location of a resource is just the starting point. In many cases, we need to do more than just retrieve data. We might need to fetch data from the server, update it, delete it, or even create new data or append it to an existing resource. To accomplish these tasks, we rely on HTTP verbs, which determine the specific action to be performed. Here's a curated list of HTTP methods and their respective meanings:

  1. GET: This method is used to retrieve data or resources from a specified server using a URL. It should only be used to retrieve data and not modify or delete it.

  2. POST: This method is used to submit data to be processed by a specified resource on the server. It is commonly used for creating new resources, such as submitting a form or creating a new user account.

  3. PUT: This method is used to update or replace an existing resource on the server with a new one.

  4. DELETE: This method is used to delete a specified resource on the server.

  5. PATCH: This method is used to update a specific part of an existing resource on the server.

  6. HEAD: This method is similar to GET, but it only retrieves the header information for a specified resource without returning the actual data.

  7. OPTIONS: This method is used to retrieve the available HTTP methods and other options for a specified resource.

  8. CONNECT: This method is used to establish a network connection to a specified resource.

  9. TRACE: This method is used to retrieve a diagnostic trace of the HTTP request and response messages for a specified resource.

Request Headers

An HTTP request header provides information to the server about the client, the requested resource, or the desired behavior of the request. The format of an HTTP request header is

Name: Value

The name and value are separated by a colon (:). The name is case-insensitive, but the value is case-sensitive.

Request headers play a significant role in API requests, as they provide additional information to the server about the request being made and allow for customization and control over the communication process. Here's an overview of some commonly used request headers:

  • Authorization: This is the most popular header common to many developers. The authorization header provides authentication credentials for the request to access the protected resource.

    The Authorization header is typically used with many authentication types such as

    Basic Authentication

      Authorization: Basic <credential>
    

    Bearer Token

      Authorization: Bearer <credential>
    
  • User-Agent: This header identifies who is making the request, i.e., what is trying to access our resource.

  • Host: This header specifies the hostname of the server that is being requested.

  • Connection: This header specifies the connection settings for the server being requested.

  • Accept: The accept header is typically used to specify the preferred MIME (Multipurpose Internet Mail Extensions) type for a particular type of content. For example, a client might specify that it prefers text/html over application/xml for web pages. The accept header is an important part of HTTP requests. It allows clients to specify their preferred MIME types, which can help ensure that the server returns a response that the client can understand.

    Here is how the Accept header can be used:

      Accept: text/html, application/xhtml+xml, */*
    

    This header specifies that the client is willing to accept text/html, application/xhtml+xml, or any other MIME type.

There are other headers such as Accept-Charset, Accept-Encoding, Accept-Language, Cache-Control, Content-Length, Content-Type, Cookie, Date, Expect, Forwarded, From, Host, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max-Forwards, Origin, Pragma, Proxy-Authorization, Range, Referer, TE, User-Agent, Upgrade, Via, Warning, etc.

Request headers are an important part of an API request. They provide additional information that can be used to improve the performance, security, and functionality of APIs. Other benefits include:

  • Increased security

  • Improved performance

  • Enhanced functionality

Request Parameters

When fetching data, sometimes we want to be specific about the data we want to fetch. Sometimes beyond this, we might want to fetch a type of data or a certain group of data. The request parameter allows us to pass an additional variable to act as a specifier/key to fetch certain values. Two types of parameters are used:

  • Route/Path parameters

  • Query parameters

Route/Path Parameters

A route parameter is also known as a path parameter or a URL parameter. It is a named URL segment that is used to capture the values specified at their position in the URL. It is a way to make parts of a URL dynamic, allowing for flexible and variable-based routing.

They're denoted by a placeholder syntax, often indicated by a colon: followed by a parameter name. Could be an id in https://example.com/users/:id. The actual value of the user's ID would replace the :id placeholder in the URL

For example,

https://github.com/<github-username>/<repository-name>/pull/16

From the above example, we can see the number 16 at the end of the URL meaning that, we are viewing the 16th pull request in a project.

Some of the benefits of Route parameters include:

  • SEO-Friendly URLs: Route parameters can contribute to creating human-readable and search engine optimization (SEO)-friendly URLs. By including meaningful identifiers in the URL path, it becomes easier for users and search engines to understand and navigate the API's resources.

  • Resource Identification: Route parameters are commonly used to identify and retrieve specific resources based on their unique identifiers. They allow for precise targeting of a particular resource within the URL path, making the API more intuitive and RESTful.

  • Strong Typing and Validation: Route parameters often allow for specific data types or formats for the values they represent. This ensures that only expected values are accepted.

Query Parameters

The request query is a string part of the URL used to pass information to the server. Here is an example of a URL that has a request query attached to it

https://github.com/Chukwuebuka2?tab=repositories

A query is usually used with a GET request alongside a key-value pair which is always appended after a question mark (?), while the key-value pair is separated with an equal to (=). Just like the example above where https://github.com/Chuwkwuebuka2 is the URL to my GitHub repo. As we saw in the route parameter where the Chukwuebuka2 is the variable that is used to fetch my account. Now after fetching my account, I want to be able to fetch my repositories, for me to access this, there is a need to pass a query with the key of tab and a value of repositories.

To allow multiple queries we use the ampersand (&) to separate the queries

Some common use of the query parameters includes:

  • Pagination and Sorting: Query parameters are used majorly for pagination and sorting purposes. Clients can specify the number of items per page, the current page number, and sorting criteria in the query parameters, enabling efficient navigation and organization of large results.

    For example,

      https://github.com/Chukwuebuka2?page=2&tab=repositories&sort=name
    

    From this URL, we can see we have the sort and the page query. The sort allows us to sort the query using the name field and the page tells us that we are accessing the second page.

  • Flexibility and Optional Filtering: Query parameters provide flexibility in API requests by allowing optional filtering and additional parameters to modify the behavior of the request. It allows for customizable and dynamic interactions with the API.

  • Simplicity and Ease of Use: Query parameters are typically easier to use and understand compared to route parameters. They can be appended to the URL in a key-value format, making it straightforward for clients to construct and modify requests without needing to modify the URL structure.

Wow! We have covered a lot of ground and still have more because I don't like to make my articles lengthy, except for the second part where we dive more into the Anatomy of an API. To receive an update when the article drops, do well to subscribe to my newsletter or follow me on any of the social media platforms.

Twitter ๐Ÿฆ: @nwokporo_ebuka

LinkedIn โšก: @chukwuebuka_nwokporo

GitHub ๐Ÿš€: @ebukvick

Hashnode ๐Ÿ“—: Nwokporo Chukwuebuka

17
Subscribe to my newsletter

Read articles from Nwokporo Chukwuebuka directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Nwokporo Chukwuebuka
Nwokporo Chukwuebuka

I'm a developer, who is keen about building solutions in the web. I love to read and write articles.