Then, in 2015, a promise-based API request, the Fetch API, was built into JavaScript ES6 to ease the process. After that, libraries like Axios and Alova also appeared.

But why would anyone consider using a third-party API when the lightweight inbuilt Fetch API is an effective option? Well, Axios and Alova provide more than just fetching simple JSON responses. While Axios automates the parsing of JSON and provides shorthand methods for requests, Alova caches responses which prevents making new requests that are redundant.

So which should you stick to – Fetch API, Axios, or Alova?

In this guide, we’ll examine each of these tools based on their features, performance, and project suitability. Walk with me…

Table of Contents

1. Prerequisites

2. The Fetch API

   • Key Features of the Fetch API

   • Limitations of the Fetch API

3. Axios

   • Key Features of Axios

   • Limitations of Axios

4. Alova

   • Key Features of Alova

   • Limitations of Alova

5. Feature-by-Feature Comparison

6. Use Cases and Best Scenarios

   • When to Use Fetch API

   • When to Use Axios

   • When to Use Alova

7. Community and Ecosystem

   • Ecosystem and Integrations

8. Conclusion

Prerequisites

Before you start this tutorial, you should have a basic understanding of JavaScript and ES6+ features, such as async/await, arrow functions, and object destructuring. Being familiar with the fetch() API will also be helpful, as we’ll compare it with Axios and Alova.

You should also have a fundamental knowledge of HTTP methods (GET, POST, PUT, DELETE, PATCH) and handling API responses based on status codes to better understand the API examples.

While this tutorial focuses on JavaScript, some examples use React. So you should be familiar with React and understand the basics of components, state, and hooks (like useState and useEffect). Alova also works with frameworks like Vue and Svelte.

Basic experience with package managers (NPM or Yarn) is useful for installing dependencies like Axios and Alova. And understanding Node.js and browser environments will help, as Alova works in both contexts.

Lastly, familiarity with state management and caching concepts will enhance your understanding of Alova’s features, as it integrates state management and caching directly into API requests.

The Fetch API

Fetch API is a promise-based API request feature in JavaScript that was released to replace the old callback-based XMLHttpRequest (XHP). Unlike the old tool, Fetch API is compatible with modern website features, including service workers and Cross-Origin Resource Sharing (CORS).

With this tool, calling API data is as simple as making a fetch() request on the API URL, as shown below:

fetch("https://fakestoreapi.com/products")

The fetch() returns the server’s promise which is fulfilled with a response object. Then, you pass in some optional arguments to configure the response as JSON or text, attach it to a variable, and use the data.

let products;

  fetch("https://fakestoreapi.com/products")

    .then((res) => res.json())

    .then((data) => {

      products = data

      console.log(products)

    })

    .catch((error) => console.error("Error fetching data:", error))

In the code above, the fetch() requests API data from the URL. The response res gets parsed as JSON res.json. Then, the resulting data is attached to the products variable and logged on the console.

Since Node.js v17.5, the Fetch API has been available natively, eliminating the reliance on external packages like node-fetch, got, or cross-fetch for handling HTTP requests. This native support in both browsers and Node.js removes the need for additional dependencies, reducing the overall bundle size of your application. With this built-in functionality, the Fetch API has become the go-to tool for making asynchronous API calls in JavaScript applications.

Key Features of the Fetch API

Promises-based syntax

As I mentioned earlier, the Fetch API uses a promise-based syntax that sends a promise from the server and executes it with a response object. While the .then chaining can be optimal for simple requests, using several .thens can lead to callback hell and give you a hard time tracking errors. This is why the async/await alternative is a more optimal solution. Check out the code example below:

const fetchData = async () => {

      try {

        const response = await fetch("https://fakestoreapi.com/products");

        if (!response.ok) {

          throw new Error(`HTTP error! Status: ${response.status}`);

        }

        const data = await response.json();

        products = data

        console.log(products); //

      } catch (error) {

        console.error("Error fetching data:", error);

      }

    };

    fetchData();

As shown above, the fetch makes a get request. Then, the server returns an error status if the response is not ok (returns an error status like error 404). Then, the response gets parsed as JSON and used.

Keep in mind that all methods passed on the response are asynchronous, including the fetch() and the json() parsing.

Supports the GET, POST, PUT, PATCH and DELETE methods

GET, used to receive responses, is the Fetch API’s default method. So when you’re using it, you don’t have to define it explicitly or attach a body. But for methods that send requests like POST, PUT, PATCH and DELETE, you must specify their method and attach a body.

All these methods send requests to the backend. You can send data to the server with POST, completely replace an existing resource with new data using PUT, partially update with PATCH, or remove the resource with DELETE.

1. Here’s how you can define a method:

In the code below, I set the POST method to send data to the specified API:

const response = await fetch("https://example.com/products1", {

          method: "POST"

          //...

        });

Apart from posting data, you can also clear data on the server using DELETE:

const response = await fetch("https://example.com/products1", {

      method: "DELETE"

      //...

    });

2. Then, define the header:

Defining the header lets the server understand the type of content you are sending for proper data handling. As shown here, the header asks the server to store the content as a JSON file and set the authorization token to my-classified-token. Keep in mind that the token is the API key that will be used to verify user identity upon use.

const response = await fetch("https://example.com/products1", {

          method: "POST",

          header: {

            "Content-Type": "application-json",

            "Authorization": "Bearer my-classified-token",

          }

          //..

        });

Here is a full list of parameters that can be passed into the header:

3. Next, attach the body:

After specifying the header, you then attach the body. The body is the data being sent to the backend server. It cannot be used with the GET method which only fetches responses. Besides, the information attached should always be in a valid format that matches the content type specified in the headers. You can add as much value as you require to the body.

const response = await fetch("https://example.com/products1", {

          method: "POST",

          header: {

            "Content-Type": "application-json",

            "Authorization": "Bearer my-classified-token",

          },

          body: JSON.stringify({ name: "Laptop", price: 1200 })

        });

Streaming Data

It is also worth noting that the Fetch API facilitates large data handling via streaming. It receives copious data in chunks instead of loading the whole data and buffering in the process. So it data displays real-time as they arrive. Here is a simple example of streaming:

 const fetchData = async () => {

const response = await fetch('https://www.example.com/large-text-file.txt');

      const reader = response.body.getReader();

      const decoder = new TextDecoder();

      while (true) {

        const { done, value } = await reader.read();

        if (done) break;

        const chunk = decoder.decode(value, { stream: true });

        console.log(chunk); // Process the chunk (e.g., display it in UI)

      }

      console.log('Stream complete');

    }

    fetchData();

Fetching Documents with the DOM Parser

Unlike its predecessor, XHP, which can directly return a document, Fetch API can’t achieve the same results without using the DOM Parser. To use it, you have to set the response type to text, then convert to a document using the DOMParser. Here is an example:

fetch("example.xml")

  .then(res => res.text()) // Get raw text

  .then(data => {

    const parser = new DOMParser();

    const doc = parser.parseFromString(data, "text/xml"); // Convert text to Document

    console.log(doc); // Now it's a Document object

  })

  .catch(console.error);

Request Cancellation with AbortController

Previously, the Fetch API couldn’t abort requests. But it is now possible with AbortController and AbortSignal. But the AbortController API is not native either, which means there is extra bundle and set up required.

Limitations of the Fetch API

Response Flexibility or No automatic JSON parsing

Depends on how you see it. Having to specify whether you want your response as JSON res.json() or text res.text() or blob res.blob() lets you set which response type you want from the get go. But it can also be a limitation since most API fetches are in JSON. This means that alternatives like Axios, which sets defaults as res.json(), helps write shorter and cleaner code, and is therefore often preferred by developers.

No built-in request/response interceptors

Unlike Axios, Fetch API does not have built-in methods that intercept and modify requests or responses. This limitation means you have to write boilerplate code to create a custom interceptor.

For instance, via interception, you can attach an Authorization token automatically before sending requests or asking all 401 errors to automatically reload when receiving responses. With the Fetch API, you have to wrap the fetch() in a function to do that, which means more lines of code.

Here is some code built to mimic request/ response interception:

const customFetch = async (url, options = {}) => {

      // Request Interception

      const modifiedOptions = {

          ...options,

          headers: {

              'Content-Type': 'application/json',

              Authorization: Bearer ${localStorage.getItem("token")}, // Interceptor behavior

              ...options.headers

          }

      };



      try {

          const response = await fetch(url, modifiedOptions);



          // Response Interception

          if (!response.ok) {

              console.error("Intercepted Error:", response.status);

          }



          return await response.json();

      } catch (error) {

          console.error("Fetch error intercepted:", error);

          throw error;

      }

  };

  // Usage (No need to set headers manually)

  customFetch('https://api.example.com/data')

      .then(data => console.log(data))

      .catch(error => console.error(error));

Error handling requires additional logic

The Fetch API only rejects network errors, not failed HTTP status codes like 404 or 501. This means that when a fetching request fails, it does not return a 404 Not Found or 500 Internal Server Error unless you configure that with additional code. But Axios does.

fetch('https://jsonplaceholder.typicode.com/invalid-url')

  .then(response => {

    if (!response.ok) { // Manually handle non-2xx responses

      throw new Error(`HTTP Error! Status: ${response.status}`);

    }

    return response.json();

  })

  .then(data => console.log(data))

  .catch(error => console.log('Error:', error.message));

Axios

After XHP was replaced with the Fetch API, Axios emerged in 2016 to address some issues with the new JavaScript-native fetching tool. Built on top of XHP, Axios quickly gained widespread adoption due to combining many Fetch API promise-based features with some methods on the legacy XMLHttpRequest. In no time, it became a popular choice amongst developers.

Axios stands out because it:

• Automates JSON parsing

• Has a built-in method to intercept and modify requests and responses

• Automates error handling

• Automates timeout handling

• Can track upload and download progress

And many more features.

In particular, Axios is widely loved because it reduces boilerplate code. Since most API requests encode data with JSON, Axios sets its default parsing to accordingly, which means you don’t have to define JSON again. And why worry anyway, since developers use far fewer res.text() and res.blob() API responses in comparison.

const fetchData = async () => {

    const response = await axios.get('https://api.example.com/data');

    console.log(response.data); // JSON is already parsed

  };

Now, compare that to a like-for-like fetching with Fetch API:

const fetchData = async () => {

    const response = await fetch('https://api.example.com/data');

    const data = await response.json(); // Extra step

    console.log(data);

  };

Yeah, there’s an extra line, right? That could mean several lines of code for larger codebases.

Key Features of Axios

Automatic JSON Parsing

As explained above, you don’t have to call res.json() again while using Axios, since the method is automatically set. But what happens, in rare cases, when you want to fetch a blob or text using Axios? Then, you have to set the response type accordingly. Here’s how you can do that:

const fetchData = async () => {
    const response = await axios.get('https://api.example.com/data', {
      responseType: 'text', // Treats response as plain text
    });

    console.log(response.data); // Plain text string
  };

Built-in Interceptors to Modify Requests and Responses

Axios comes with its built-in interceptors to intercept and modify API responses or requests. Interceptors can help set authorization tokens for requests or modify global responses and errors before they render. Use the .interceptors.request.use() for requests and .interceptors.response.use() for responses.

import axios from "axios";

  const apiClient = axios.create({

      baseURL: "https://api.example.com",

      headers: {

          'Content-Type': 'application/json'

      }

  });



  // Request Interceptor: Attach Authorization headers

  apiClient.interceptors.request.use(config => {

      config.headers.Authorization = Bearer ${localStorage.getItem("token")};

      return config;

  }, error => Promise.reject(error));

  // Usage: Axios automatically includes the Authorization header

  apiClient.get("/data")

      .then(response => console.log(response.data))

      .catch(error => console.error(error));

To achieve that with Fetch API, you will have to write an interceptor wrapper on your API, which needs far more boilerplate code.

Request cancellation with CancelToken

Although now deprecated, Axios used to have its native request cancellation method known as CancelToken. But now, the AbortController API is regarded as a globally-recognized and reliable method for request abortion.

Error Handling

Axios handles errors better by automatically rejecting all non-2xx status codes like Error 404 and 501. You do not need to check any response.ok message:

axios.get('https://jsonplaceholder.typicode.com/invalid-url')

  .then(response => console.log(response.data))

  .catch(error => {

    console.log('Error Status:', error.response?.status); // Axios auto-rejects non-2xx responses

    console.log('Error Message:', error.message);

  });

Built-in Progress Tracking

Axios incorporates XHP methods like onDownloadProgress and onUploadProgress. This inbuilt feature facilitates tracking download and uploads progress. Whereas with the Fetch API, you’d need ReadableStream to achieve similar results.

Here is an example showing how you can use onUploadProgress:

axios.post(url, data, {

    onUploadProgress: progressEvent => console.log(progressEvent.loaded)

  });

Supports Other Methods, too

Just like the Fetch API, Axios’ default Method is GET. But you can use the POST, PUT, PATCH or DELETE methods using axios.request(). Here’s how:

import axios from "axios";

  axios.request({

      method: "POST",

      url: "https://api.example.com/users",

      body: { name: "Abdullah", age: 25 }, // Request body

      headers: {

          "Authorization": Bearer ${localStorage.getItem("token")},

          "Content-Type": "application/json"

      }

  })

  .then(response => console.log(response.data))

  .catch(error => console.error("Axios Request Error:", error));

Axios also provides a shorthand with methods like axios.get, axios.post, axios.put, axios.patch, and axios.delete, as shown below:

// POST Request

axios.post("https://api.example.com/users",

  { name: "Abdullah", age: 25 }, // Request body

  { headers: { "Content-Type": "application/json" } }

)

.then(response => console.log(response.data))

.catch(error => console.error("Axios POST Error:", error));

// PUT Request

axios.put("https://api.example.com/users/123",

  { name: "Updated Name" }, // Updated data

  { headers: { "Authorization": Bearer ${localStorage.getItem("token")} } }

)

.then(response => console.log(response.data))

.catch(error => console.error("Axios PUT Error:", error));

// DELETE Request

axios.delete("https://api.example.com/users/123", {

  headers: { "Authorization": Bearer ${localStorage.getItem("token")} }

})

.then(response => console.log("User deleted successfully"))

.catch(error => console.error("Axios DELETE Error:", error));

Limitations of Axios

Slightly larger bundle size

Axios adds 35 kb of extra bundle, while FetchAPI adds 0. While Axios clearly offers more features than Fetch in every other metric, you have to make do with the larger bundle size. And in an age where lightweight and fast applications are often preferred, you might not want that load.

Dependency on third-party maintenance

Depending on a third-party option for something as crucial as API might not be desirable. So a native tool like the Fetch API, built within JavaScript, offers more reliability.

Alova

Alova is a request management library that combines simple API fetching with other functionalities like state management, hooks, and caching, amongst many others.

While we use react-query and SWR to process Axios-fetched data, Alova saves you those extra installations and coding by providing these methods natively. The all-in-one alternative not only fetches responses and sends requests, but also merges requests, caches responses, and optimizes them for UI frameworks.

Built in 2022, Alova’s adoption is still early but nonetheless seems promising. It is supported on browsers, Node.js, and most frameworks, including Vue, React, Svelte, and vanilla JavaScript. But it has limited usage for Angular.js.

At just 10kb, it is about 3 times smaller than Axios, making it a more lightweight alternative for building fast applications.

You can also use Alova to either replace react-query to facilitate Axios or be the one-stop-shop for everything API integration-related.

Here is a simple Alova fetch:

const response = await alovaInstance.Get('https://jsonplaceholder.typicode.com').send();

console.log(response); // Response data

When you are fetching Alova on React components, you can use the createAlova() to set parameters and useRequest() to manage state.

import React from "react";

import { createAlova, useRequest } from "alova";

import GlobalFetch from "alova/GlobalFetch";

// Initialize Alova

const alovaInstance = createAlova({

  statesHook: React,

  requestAdapter: GlobalFetch(),

});

// GET request with useRequest

const Profile = () => {

  const { data, loading, error } = useRequest(() => alovaInstance.Get("https://jsonplaceholder.typicode.com"));

  if (loading) return <p>Loading...</p>;

  if (error) return <p>Error fetching profile</p>;

  return <div>Username: {data.username}</div>;

};

export default Profile;

Key Features of Alova

One-Stop Shop

For some functionalities that come built into Alova, Fetch API or Axios might need additional libraries like react-query or SWR to fulfill.

Request Sharing Prevents Redundant Requests

Alova fuses identical requests. Let’s say several components ask for the same data from the API. The Fetch API and Axios send multiple identical requests to the server which creates traffic. But Alova merges them, sends a single request, and shares its response across all components, which reduces network traffic.

State Management

With tools like Fetch API and Axios, you have to manage data, loading, and error states manually. Alova lets you do that on the go within a single line of code. Here is how it looks:

//...

const { data, loading, error } = useRequest(alova.Get("/posts/1"));

//...

Advanced Request Management

Alova offers several request management functionalities with each tailored to specific use cases. With its request management, you can request preload for data to be used later, cache data to prevent reload, manage form submission, handle pagination, and automate refetching when needed. Check out their docs to read more.

Multi-Level Caching

You can also use Alova to cache data, especially when the response isn’t constantly changing and does not need refetching. Unlike react-query that simply stores caches in RAM, Alova offers a more flexible framework.

Its three-pronged caching modes include the memory mode, cache occupying mode, and recovery mode. While memory mode stores data in the RAM, recovery mode persistently stores it in a Local Storage and is made available for longer periods and even offline. Meanwhile, the occupying mode prevents duplicate or redundant requests coming in quick succession.

Independent on any component, cached data can be accessed anywhere in the app if the request URL and parameters match. These features lower traffic going to servers, reduce buffering, and help facilitating a swifter and better user experience.

//...

// Initialize Alova instance

const alovaInstance = createAlova({

  baseURL: "https://jsonplaceholder.typicode.com",

  statesHook: React,

  requestAdapter: GlobalFetch(),

});

// Define GET request

const getPosts = alovaInstance.Get("/posts", {

  cache: {

    mode: "memory", // Caches in memory

    expires: 1000 * 60 * 5, // Expires in 5 minutes

  },

});

const PostList = () => {

  const { data, loading, error } = useRequest(getPosts);

  if (loading) return <p>Loading...</p>;

  if (error) return <p>Error fetching data</p>;

  //...

};

In the example above, Alova caches the response using the memory mode cache: {mode: "memory"} and sets the cache expiration to 5 minutes expires: 1000 * 60 * 5. You can change “memory” to “recovery” if you want a longer storage duration.

Usage Flexibility

You can use Alova with either Axios or the Fetch API. Here is an example where I fetched data using Axios and complemented it with Alova state management.

//...

// Initialize Alova

const alovaInstance = createAlova({

  statesHook: React,

  requestAdapter: GlobalFetch(),

});

// Manage state with Alova

const { data: posts, setData } = useSnapshot([]);

const fetchPosts = async () => {

  const response = await axios.get("https://jsonplaceholder.typicode.com/posts");

  setData(response.data); // Store data in Alova state

};

//...

Supports Other Methods

Alova also makes GET its default option while supporting other methods like POST, PATCH, PUT and DELETE. Here is how to use POST in Alova, for example:

import React, { useState } from "react";

import { createAlova, useRequest } from "alova";

import GlobalFetch from "alova/GlobalFetch";

const alovaInstance = createAlova({

  baseURL: "https://jsonplaceholder.typicode.com",

  statesHook: React,

  requestAdapter: GlobalFetch(),

});

const PostForm = () => {

  const [title, setTitle] = useState("");

  const { send: createPost } = useRequest(alovaInstance.Post("/posts", { title }), { immediate: false });

  createPost().then(console.log)

};

export default PostForm;

Of course, it has shorthand methods too:

import React, { useState } from "react";

import { createAlova, useRequest } from "alova";

import GlobalFetch from "alova/GlobalFetch";

const alova = createAlova({

  baseURL: "https://jsonplaceholder.typicode.com",

  statesHook: React,

  requestAdapter: GlobalFetch(),

});

const { send: createPost } = useRequest(alova.Post("/posts", { title: "New Post" }), { immediate: false });

const { send: updatePost } = useRequest(alova.Put("/posts/1", { title: "Updated Post" }), { immediate: false });

const { send: patchPost } = useRequest(alova.Patch("/posts/1", { title: "Patched Post" }), { immediate: false });

createPost().then(console.log);

updatePost().then(console.log);

patchPost().then(console.log);

Bundle Size

Alova is three times smaller than Axios, but that does not even tell the full story. With Axios and the Fetch API, you need different libraries to handle caching, request deduplication, and retries. But Alova has everything in-built. So using Axios and Fetch API in real code production will always require more bundles than Axios. And overall, Alova facilitates lighter-weight applications compared to Axios and sometimes the Fetch API as well.

Limitations of Alova

Adoption Is Still Low

While writing this article, I had a hard time getting enough resources on Alova. And that is because it only debuted in July 2022 which means adoption is still early. So, troubleshooting Alova might be problematic since there are fewer Alova-themed API communities, as well as fewer StackOverflow answers, Youtube Tutorials, or GitHub contributions.

Potential Stability & Long-Term Maintenance Risks

Newer libraries have a higher risk of abandonment. Axios has been around for years, while Alova is still growing. Besides, it has fewer production use cases and battle-tested applications compared to Axios and Fetch.

Learning Curve

Alova’s learning curve can take some getting used to because it handles API requests differently from tools like Axios or the Fetch API.

Instead of making requests directly, you work with request instances and manage state within Alova’s system. This requires learning new ways to structure API calls and use features like caching and request merging. While it may feel unfamiliar at first, it can help reduce redundant API calls and improve performance once you understand it.

Fewer Third Party Integrations

Alova has fewer third-party libraries built specifically for it, requiring more manual work for compatibility with existing tools.

Feature-by-Feature Comparison

Use Cases and Best Scenarios

Choosing the right HTTP client for your project depends on several factors, including project complexity, dependencies, and performance considerations. Let’s explore when it’s best to use the Fetch API, Axios, or Alova.

When to Use Fetch API

1. Suitable for Lightweight Projects and Simple Requests

The Fetch API is built into modern browsers and is ideal for handling basic HTTP requests without adding dependencies. If your project requires only simple GET, POST, or DELETE requests with minimal configurations, Fetch API is a great choice.

2. When Working in Environments Where Third-Party Libraries Are Restricted

Certain enterprise or security-sensitive applications may restrict the use of external libraries. Since the Fetch API is built into the browser, it remains a viable option when third-party packages like Axios or Alova are not allowed.

3. When Minimal Dependencies Are Preferred

Since Fetch API is native to JavaScript, it does not require installing extra libraries, making it perfect for projects that need to keep dependencies low. This can be particularly beneficial for small lightweight apps or static websites.

When to Use Axios

1. Ideal for Backend-Heavy Applications or Complex APIs

For projects that require multiple API calls, error handling, and efficient request management, Axios is a solid choice. It allows concurrent requests, request cancellation, and improved control over HTTP headers.

2. When Automatic JSON Handling, Interceptors, and Robust Error Handling Are Needed

Axios simplifies working with JSON data by automatically parsing responses. It also provides built-in interceptors for request and response transformations, as well as superior error handling compared to Fetch API.

3. Useful When Working with Node.js in Full-Stack Applications

Axios works both in the browser and in Node.js, making it an excellent choice for full-stack applications where a unified API client is needed across the frontend and backend.

When to Use Alova

1. When Working with Frontend-Heavy Applications (React, Vue, Svelte)

Alova integrates well with frontend frameworks and state management tools, making it a great choice for single-page applications (SPAs) that depend on smooth data fetching, pagination, and updates.

2. Best for Projects Requiring Optimized Caching and Data Synchronization

Alova is designed for performance optimization and better caching strategies. It is suitable for applications that rely on real-time data synchronization and need to minimize redundant network requests.

3. When Performance Optimization and Reduced Network Load Are Priorities

With its intelligent caching mechanisms, Alova can significantly reduce API call frequency, thereby improving the overall performance of the application. It is especially useful in scenarios where network efficiency is crucial, such as mobile applications or progressive web apps (PWAs).

Community and Ecosystem

The community and ecosystem surrounding an HTTP client can impact ease of use, available learning resources, and integration with other tools. Let's explore how the Fetch API, Axios, and Alova are perceived in 2025.

Ecosystem and Integrations

While Fetch API is widely supported, developers often supplement it with additional libraries for improved caching, timeouts, and request queuing. This can lead to increased development effort compared to using an out-of-the-box solution like Axios or Alova.

Meanwhile, Axios benefits from a well-established ecosystem with a variety of plugins and extensions, making it easy to integrate with different backend architectures, authentication systems, and request monitoring tools.

Alova is designed to work seamlessly with modern state management libraries such as React Query and Vue Query. These integrations make it an attractive choice for developers focused on optimizing frontend data fetching strategies.

Conclusion

Choosing between the Fetch API, Axios, and Alova depends on your project’s needs and priorities. The Fetch API is best for lightweight applications that require minimal dependencies, while Axios is a robust choice for full-stack applications and backend-heavy environments. Alova, on the other hand, is an excellent option for optimizing data fetching and caching in frontend-focused applications.

As developers explore new ways to enhance performance and reduce network load, Alova's adoption is expected to grow, particularly in SPAs and PWAs. But Axios remains a reliable and widely adopted solution, while the Fetch API continues to be the fundamental building block for HTTP requests in JavaScript.

But how do applications interact with each other? Well, they do it through APIs – Application Programming Interfaces. In this article, you’ll learn what APIs are. We’ll specifically focus on Web APIs and their design and development.

What is a Web API?

Web APIs are a type of API designed to be used over the web. In other words, web-based software applications, systems, and services use Web APIs to exchange information over the internet. They send requests and receive responses, typically in formats such as JSON or XML.

Web APIs play a crucial role in modern software development for the following reasons:

1. Interoperability: APIs are technology-agnostic, meaning they allow different software systems to communicate with each other regardless of the technology stack. This enables developers to integrate various applications seamlessly.

2. Scalability: Web APIs support modular development, enabling different components of an application to be built, debugged, and scaled independently. This greatly improves the system's scalability.

3. Flexibility and Extensibility: By following standard practices and well-defined rules, Web APIs help applications extend their functionality. They are also flexible enough to allow developers to create dynamic applications.

Approaches to Developing Web APIs

Web APIs can be developed using various methods based on the requirements. Here are some commonly followed approaches:

• REST – Representational State Transfer (REST) APIs use the HTTP protocol to perform operations. They operate in a stateless manner, meaning each request must include all the necessary information for the receiver to process and respond.

• SOAP – Simple Object Access Protocol uses XML to exchange information in a structured way.

• GraphQL – used for querying and manipulating APIs.

• gRPC – a Remote Procedure Call framework that uses HTTP/2 for transporting information.

In the upcoming sections, we will explore the design and development of APIs, focusing on REST APIs as the protocol central to our discussion.

Understanding the Requirements and Objectives

In any software development process, it's crucial to understand the requirements and intended use-case before starting. This helps you plan and estimate the cost, time, and other resources you’ll need for the project.

The same applies when building RESTful APIs. You need to determine if the applications will exchange information in a stateless manner, if the entities involved can be represented as resources, and if the services are flexible enough to work with different data formats.

Defining the Resources and Endpoints

REST APIs revolve around resources, which are entities representing the data or objects in the system. Each resource is identified by a unique URI called a resource identifier. These resources can be accessed and manipulated via endpoints, which are specific URLs that receive and process requests from the client.

Best practices suggest using nouns for resources in the endpoints instead of verbs that might indicate an operation on the resource.

Consider the following example: https://api.example.com/products

The endpoint follows the best practice of using a noun for the resource (in this case, products). Notice how I used the plural form - products? It is also advisable to use plurals if you are working with a collection of objects.

However, the following endpoint https://api.example.com/add-product is not recommended because it uses a verb and tries to describe an action on the resource. This approach can become complicated for more complex operations.

Another important aspect of standard endpoint naming convention is using a hierarchical structure. This helps to clearly represent the relationship between resources.

For example: https://api.example.com/categories/{categoryId}/products/{productId}.
Here, we define an endpoint that maintains a clear hierarchy between the category and product resources.

Using HTTP Methods and Status Codes

In REST APIs, HTTP is used for communication between the client and the server. HTTP has standard methods that are primarily used to perform operations on resources. Below is a list of these methods along with their purposes:

• GET – Fetch the details of the resource. These details are returned by the server in the response message body.

• POST – Create a new resource. The details of the resource to be created are sent in the request message body.

• PUT – Create or update a resource, depending on its availability. The details of the resource to be created or updated are sent in the request message body.

• DELETE – Remove a resource.

• PATCH – Partially update a resource. The changes to be made to the resource are sent in the request message body.

The recommended approach to developing a well-defined REST API is to use these HTTP methods correctly for performing the corresponding CRUD (Create, Read, Update, Delete) operations on the resource. Also, you should make sure that the API responds back to the client with an appropriate HTTP status code in the response message body.

Status codes reflect the end result of a request. Below are some of the common HTTP status codes you can use:

• 200 OK

• 201 Created

• 204 No Content

• 400 Bad Request

• 401 Unauthorized

• 403 Forbidden

• 404 Not Found

• 500 Internal Server Error

• 503 Service Unavailable

• 504 Gateway Timeout

Use a suitable HTTP status code that accurately represents the outcome of the request your API endpoint is processing. You can also implement custom HTTP status code to describe application-specific behavior.

Versioning Strategies

Over time, the API you develop will evolve, and you will make changes to it. This is where versioning strategies become important. You must ensure that the clients already using your APIs are not affected by the changes you make.

Maintaining different versions will make your APIs backward compatible and allow clients to use the preferred version of the API based on their needs. An excerpt from this informative blog on the Postman website explains when it is ideal to version your APIs:

“You should version your API whenever you make a change that will require consumers to modify their codebase in order to continue using the API. This type of change is known as a “breaking change,” and it can be made to an API's input and output data structures, success and error feedback, and security mechanisms.“

API versioning can be done in different ways. Here are some methods:

• URI Versioning: Include the version number in the URL path. For example, https://api.example.com/v1/products.

• Query Parameter Versioning: Specify the version number as a query parameter in the URL. For example, https://api.example.com/products?version=1.

• Header Versioning: Include the version number in the HTTP headers of the request. For example, using a custom header like X-API-Version: 1.

• Content Negotiation: Specify the version in the Accept header of the request, often using media types. For example, Accept: application/vnd.example.v1+json.

• Embedded Versioning: Embed the version number within the media type of the response. For example, application/vnd.example.product-v1+json.

Security Considerations

Another important aspect to consider when developing an API is security. Here are some key points to remember:

1. Implement HTTPS to encrypt the information exchanged between the client and the server.

2. Implement authentication and authorization to ensure that only users with the right privileges can perform operations on the resources. Common methods include Basic authentication, Bearer or Token authentication, JWT, and OAuth 2.0. Also, implement role-based access control to manage resource access.

3. Implement input validation and sanitization to prevent vulnerability attacks like SQL injection and Cross-Site Scripting (XSS).

4. Implement rate limiting and throttling to control the number of requests a client can make to the server within a specific time frame. This helps prevent excessive load on the server.

Documentation

One key but often overlooked aspect of API development is documentation. It is crucial to document your API so users understand its features and functionalities.

The documentation must be comprehensive, easy to understand, and follow standard practices. Include examples of request and response bodies, HTTP status codes used, and more. You can follow the Open API specification for describing your RESTful APIs.

Sorting, Filtering and Pagination Strategies

The API you develop might cause performance issues if it returns too many records. It's inefficient to retrieve large amounts of data and then sort or filter it.

To address this, you should enable sorting and filtering of records. You should also implement pagination to break down the number of records being fetched and set a limit for easier navigation and processing.

Monitoring Usage, Logging, and Health

It’s a good idea to log your API requests and responses to help with debugging. Monitoring API usage will help you understand the overall performance and behavior of the application. Performing regular health checks can help you take necessary action if there are any issues. All these steps will make the API more robust and reliable.

Conclusion

APIs, specifically Web APIs, are essential for software applications to communicate over the internet.

This article explained what Web APIs are, why they’re important, and different approaches for developing them, focusing on REST APIs. You also learned about key topics like defining resources and endpoints, using standard HTTP methods and status codes, versioning strategies, security considerations, documentation, and more.

If you found this article interesting, feel free to check out my other articles on freeCodeCamp and connect with me on LinkedIn.

In this guide, I’ll introduce you to Postman, a popular API development and testing tool.

If you are a beginner mainly focused on frontend development, you may not have had much experience fetching data from an API. And in that case you probably haven't encountered many situations where you need to make multiple requests to an API for testing purposes during your development process.

But understanding how to test APIs and connect with them via Postman or similar tools will become important at some point in your career. If you decide to venture into backend development, understanding these concepts is essential.

After covering some basic information about Postman and the Spotify API documentation, we’ll dive into more key Postman features. Then, we’ll select one Spotify endpoint and walk through the process of making requests to it.

🔐 Here's What We'll Cover

• You'll gain fundamental knowledge of working with Postman.

• You'll strengthen your ability to work with APIs and their documentation.

• You'll explore the basics of the public Spotify API.

📝 Prerequisites

• You should have a basic understanding of APIs.

• You don't need any prior knowledge of Postman.

Table of Contents

1. Exploring the Spotify API with Postman

2. The Postman Experience

3. How to Make Your First Request to the Spotify API

4. Spotify API Authorization

5. Spotify API Authorization Scopes

6. Summary

Exploring the Spotify API with Postman

To get a brief overview of what Postman is, let's refer to the following explanation from ChatGPT:

"Postman is a popular API (Application Programming Interface) development and testing tool that simplifies working with APIs by providing an easy-to-use interface for sending HTTP requests and receiving responses. It's widely used by developers, QA engineers, and teams who work with APIs to ensure they function correctly and efficiently."

While we will focus on making HTTP requests, it's important to note that Postman is also versatile and can be used to work with GraphQL, gRPC, WebSocket, Socket.IO, and MQTT.

With Postman in hand, we need an API endpoint to test. For this, we’ll use the public Spotify API, which offers a variety of endpoints for different use cases. This can even be an exciting opportunity for your next project if you're a beginner looking for a fun project to explore.

The Spotify Web API is professionally designed, offering all the necessary information for developers. With their "Overview" and "Getting Started" sections, it's straightforward to follow along, even for beginners.

While learning the basics of Postman, we will explore key parts of the Spotify API documentation necessary for successful API testing. For instance, we will demonstrate how to make an HTTP request to the endpoint for retrieving data from a playlist.

But first, let’s cover some Postman fundamentals.

The Postman Experience

You can use Postman in a number of different ways. In my case, I'm using the desktop version of Postman.

But you can also use Postman directly in your browser, or even via the Postman CLI (Command Line Interface). There's also an official Postman extension for VS Code. You can find these versions through the link I just shared.

If you're completely new to Postman, you may want to start with the web version or the downloadable desktop version, especially if you plan to use Postman regularly in the future.

After starting the desktop version of Postman, the first thing you’ll see is this:

This might look slightly different from what you see initially. I already have an account. You may need to create one first for free. You also may need to create a workspace first. In my case, I’m already inside the "My Workspace" workspace.

In the upper left corner, you'll find several tabs, including "Collections", "Environments", "History", and an icon to configure this sidebar.

For now, we’ll stay on the "Collections" tab and click on "Create Collection":

Once you click on that, your focus will shift to the name of the collection in the top center. By typing, you can rename your collection from "New Collection" to something more appropriate for your specific use case.

For this case, I named the collection "Spotify API":

Now, we have a collection, but what exactly is that? A collection is essentially a space to organize multiple request structures. This will become clearer once we add our first HTTP request. You can do this by clicking on the blue text that says "Add a request":

When you do that, your focus will again be on the name of the element. If you type something now, you can rename the request from "New Request" to something more appropriate for the situation. In this case, since I’m not sure which request I want to create yet, I'll simply call it "test" for now.

If you'd like to create another request at this point, you can click on the three dots to the right of the collection's name (the 6th option):

There are multiple options you can choose from, with "Add request" being one of them.

At this point, we've created a collection within our workspace, and inside that collection, we've added an HTTP request. You can have multiple collections, each containing multiple requests. This helps organize your requests, especially when you reach a point where having one large list of pre-configured requests becomes cumbersome to manage.

On the newly created HTTP request, we can see some details:

The first thing you might notice is the HTTP request method, which is set to "GET" by default. If you click on "GET" with the downward arrow, you can choose from various methods or even type in your own if needed.

To the right of that, there’s a text field where you'll enter your API’s URL along with its endpoint (we'll try this shortly).

Below, there are several important tabs. Right now, we're on the "Params" tab. Here, you can add key-value pairs that will directly modify the request you're making. These are called Query Params, which you may have encountered before. For example, if your URL is https://google.com, adding a key-value pair as a Query Param might look like this:

As for Query Params, whether you need them depends on the request you're making. A common use case would be pagination on a website with a table. For example, you might use a query param like "page=4" to specify which page of results you want.

Next is the "Authorization" tab, which handles authentication and authorization for your request. We’ll cover this in more detail later, so we’ll skip it for now.

Then, we have the "Headers" tab, which is crucial because it contains all the information included in your request’s header, such as any authorization data if that’s set up.

Finally, the "Body" tab, located to the right, is also quite important. For instance, if you’re making a POST request to add an item to a database, you’d likely need to send information such as the item’s name or category. This kind of data is often included in the request body in JSON format.

To add JSON-formatted data, you can click on "raw" within the "Body" tab, and then select the format you want (with "JSON" being the default option):

As with Query Params, the format and data required depend heavily on the API and endpoint you're using. Just keep in mind that you can configure all the necessary options within these tabs.

The remaining two tabs are "Scripts" and "Settings." In the "Scripts" tab, you can add custom code, but this is more advanced and not necessary for our current situation. The "Settings" tab allows for adjustments, though in most cases, you won’t need to modify anything here.

How to Make Your First Request to the Spotify API

Now, we’ll make our first actual request using Postman. For this, we can dive into the Spotify API developer documentation, where all endpoints are listed. For this first test, we’ll fetch data about a playlist.

In that description, you’ll find a wealth of useful information, including the endpoint and the required data for a successful response. You also have the option to make the request directly from the page after logging in with your Spotify account:

Such extensive API documentation is incredibly helpful and makes it easy to work with, especially for beginners. Keep in mind, though, that not all API documentation is this thorough.

In this case, we can see the endpoint is https://api.spotify.com/v1/playlists/{playlist_id}, with playlist_id being the only required parameter in the curly brackets. You’ll also see optional parameters like market, fields, and additional_types, which can help refine the response. But again, these are optional, and you only need playlist_id for the basic request.

If you want to include optional information, like market, you’d use the Query Params mentioned earlier. For example, adding ES as the market alongside the playlist_id would change the URL to: https://api.spotify.com/v1/playlists/3cEYpjA9oz9GiPac4AsH4n?market=ES.

To make the basic request in Postman (without any optional parameters), we’ll return to our "test" request and enter the URL with the corresponding endpoint:

This approach will work, but I recommend another method.

Since we have our Spotify API collection and may want to add multiple requests to that collection, it's a good practice to use variables for sections of the URL or information that will remain consistent across multiple requests. In this case, the base URL, https://api.spotify.com/v1/, will stay the same for all Spotify API requests. Instead of manually adding it to every request, we can create a variable for it.

To do this, we’ll switch to the "Environments" tab in the upper left corner. From there, click on the plus icon to create a new environment:

We'll name the environment “Spotify API”.

Next, we'll create variables, such as base_url, and assign the appropriate value to it. You can also choose between the type options: default or secret. Since this isn't sensitive data, it can remain set to default. If you choose secret, you'd need to click on an eye icon to reveal the variable’s value each time, otherwise, it would be masked with ••••, similar to how passwords are displayed.

Here’s what it looks like so far:

Next, we’ll return to the Spotify API collection and look at the upper right corner, where it currently says "No environment". Click there and select the "Spotify API" environment that we just created:

Now, we can use the variables from that environment for all the requests within the "Spotify API" collection. To insert a variable, you’ll use double square brackets, like this:

If you receive a message that the variable couldn't be found, make sure to save the "Spotify API" environment. The dots on the right of the tab names indicate that you can save new information by pressing CTRL + S, for example. This step is necessary for the created variable to be recognized.

With the variable in place, you can now modify just this one variable to change the base_url for all your corresponding requests. While this may not seem immediately useful for the base_url, since it likely won’t change anytime soon, variables can be incredibly helpful in other scenarios. This was an opportunity to introduce you to how they work.

Next, I’ll rename the HTTP request from "test" to something more descriptive, like "Playlist," to indicate what this request is about. Along with the "GET" method, it will be clear that this request is for fetching playlist data.

Now that everything is set, let's send the request by clicking the "Send" button on the right while viewing the HTTP request. You’ll see the response appear in the bottom half of the screen:

What a bummer, the request wasn’t successful!

This happened because we didn’t provide any authorization. That’s why we received a "401 Unauthorized" error with the message "No token provided".

Since this is a protected endpoint, we need an access token, which you would obtain by logging into Spotify. If you tried making a request on the Spotify API documentation website earlier, you probably noticed that it asked you to log in before sending the request. By doing so, it acquired your session's access token, which is exactly what we need in our situation as well.

However, instead of logging in with our username and password, we’ll use a different authorization method.

Spotify API Authorization

To make basic requests to the Spotify API, you'll need an access token, which can be generated using your credentials. This is a common approach with many APIs, where you need to obtain an access token before you can access the endpoints you're targeting.

The Spotify Developer API provides a step-by-step guide on how to get your access token.

Following the outlined steps, the first task is to create an application profile, which you can do in just a few seconds, especially for a test project:

After completing this step, we can proceed by clicking on the "test" project to navigate to the "Settings" of the project. Here, you'll find the "Client ID" and "Client Secret":

Keep in mind that this information is generally considered sensitive, so you should avoid sharing it publicly (in most cases). But since this is just a test project, which will be deleted by the time this guide is published, I am showing it to make it easier for you to follow along with my explanations.

With your Client ID and Client Secret in hand, you now have the information needed to request an access token. These access tokens are used to authorize yourself when interacting with API endpoints.

You can kinda compare this to logging into software, where you need to authenticate yourself before accessing certain information. In such cases, it’s likely that an access token is generated for the duration of your session to authorize your requests to the software’s backend API.

Also, remember that access tokens change with each login session, meaning you receive a different token every time. Just keep in mind that with our current selected method, we don’t have access to specific user information. Instead, we only can make basic GET requests without acting on the behalf of a user. Later on we will cover this a little more.

The Spotify API documentation is quite helpful and provides detailed instructions on the exact request you need to make. We’ll now jump into Postman for this step.

Go to your "Spotify API" collection and click on the "Authorization" tab. Here, you need to choose the appropriate "Auth Type". There are several options, and the authorization method can differ depending on the API you’re using.

If you already have an access token, you may opt for the "Bearer Token" auth type, where you simply paste the token directly. This is the type of authorization we’ll use in the end. But instead of manually requesting a token and then inputting it into the "Bearer Token" field, we can automate this process. For this, we’ll select "OAuth 2.0" as the auth type.

How did I know "OAuth 2.0" was the right choice? If you check the Spotify API documentation, you’ll find some corresponding information while going through their step-by-step guide. Also, all endpoints that need authorization are tagged with "OAuth 2.0", including the "Get Playlist" endpoint:

The documentation also mentions that Spotify uses "Client Credentials" for its tutorial. This is the "grant type" and indicates the information you’ll provide for the authorization request. With "Client Credentials," you pass your Client ID and Client Secret (the information from our test application).

For instance, with the "Password Credentials" grant type, you would also pass a "Username" and "Password," which is used when logging in with an actual user account.

There are other authorization methods as well, and the API documentation usually specifies which approach to use. In our case, since we have the Client ID and Client Secret and don’t need specific user access, we know the "Client Credentials" grant type is the appropriate choice.

When passing your Client ID and Client Secret in Postman, you may receive a suggestion to use variables for this information:

Similar to the base_url variable we used earlier, creating variables for the Client ID and Client Secret can be helpful, especially if you plan to use multiple HTTP requests with similar authorizations. This way, you can reference the same variables in all your requests, and if anything changes, you only need to update the variable in one place.

In this case, we’ll do the same by switching to the "Environments" tab and adding variables for both client_id and client_secret.

Next, you’ll insert those variables into the authorization process we started earlier:

Now, we just need to add the token authorization URL, which can be found on the same page as before: https://accounts.spotify.com/api/token. Enter this into the "Access Token URL" field. Then, give the setup a fitting name of your choice and scroll down to click the "Get New Access Token" button:

It was successful! Now, click on "Proceed" to view more details about the generated access token:

With our access token ready, click on "Use Token" in the upper right, and Postman will confirm that the token has been added.

Now, if we switch to the "Playlist" GET request we created earlier, you’ll see the option to set up an authorization method for this specific request. But since we’ve already set up authorization for the entire collection, simply select "Inherit auth from parent" as the "Auth Type" for this request:

Postman will indicate which authorization type is being used and where it’s coming from. In this case, it will say: "The request is using OAuth 2.0 from collection Spotify API."

Next, if we switch to the "Headers" tab and click on "8 hidden," we can see an "Authorization" key. By clicking on the eye symbol to the right, we can reveal this information.

If you compare this with the access token we just generated, you'll notice they are the same (with "Bearer" in front of the actual access token). When you create a new token for the collection, as we did earlier, this information updates automatically.

With everything set up, we are now ready to send the request we tried earlier, this time with a valid access token in the "Authorization" header.

And if we now hit "Send", we will get a response like this:

The response is a JSON object containing a lot of information to explore. You can do this for your own playlist as well, as long as it’s set to public on Spotify.

To give another example, I’ll go to Spotify, use the "Share" option for my playlist, and copy the playlist link, which looks like this: https://open.spotify.com/playlist/1OPgvkPckzXm9SB0CIJf3o?si=cbe9c361f8024abd.

The part we’re interested in is the playlist ID, which is found after the last forward slash and before the question mark—in this case, 1OPgvkPckzXm9SB0CIJf3o. We’ll replace the current playlist ID with this one in Postman:

Now, if we hit "Send," we’ll receive the corresponding JSON response:

This response is also a large JSON object with plenty of data to explore.

And that's it! We've successfully configured a fundamental Postman setup with an HTTP GET request, including authorization, to fetch data from the Spotify API.

Spotify API Authorization Scopes

By now, we’ve successfully used authorization with our Client ID and Client Secret. But if you dive deeper into the Spotify API documentation, you’ll find situations where this method of authorization is insufficient for certain actions.

While fetching playlist data and other GET requests work with Client ID and Client Secret authorization, you may encounter endpoints that use POST, PUT, or DELETE methods.

For example, adding new songs to a playlist requires more than just Client ID and Client Secret authorization. You need to authenticate as the actual user associated with the playlist.

In such cases, the documentation lists "Authorization scopes" that define the required permissions. For instance, "playlist-modify-public" and "playlist-modify-private" scopes are needed for modifying public and private playlists, respectively:

If you review the Spotify API documentation, you’ll see that it outlines four main authorization methods:

• Authorization code

• Authorization code with PKCE extension

• Client credentials

• Implicit grant

The Client credentials method (which we used) does not provide access to user-specific data. To perform actions on behalf of a user, such as modifying their playlists, the "Authorization code" method is required.

In real-world projects, you would typically implement this as part of your app's authentication and authorization process when users log in. For instance, in Next.js projects, NextAuth offers a Spotify login mechanism that simplifies this process.

Alternatively, you could manually handle the necessary requests during the authentication process and add relevant data to the session information.

This topic goes beyond the scope of this guide, as it deals with general authorization and authentication flows for the Spotify API (and other APIs) rather than Postman-specific use cases. But the Spotify API documentation provides valuable resources if you’re interested in exploring more advanced testing with Postman. They also provide a how-to guide on retrieving a user's profile data and displaying it in your frontend application.

Summary

In this guide, we covered the fundamentals of Postman: how to set up your first workspace with a collection, create an HTTP request, use variables to simplify the process for future requests, and add authorization logic to obtain an access token required for making requests. All of this was demonstrated using the Spotify API, which provides extensive documentation on accessing its endpoints.

From here, you might want to explore deeper by learning how to access Spotify API endpoints that require user-specific access information, combined with specific scopes, such as adding new songs to a Spotify playlist.