Getting to grips with making REST API calls felt like finally being able to have a real conversation with the internet. At first the whole thing was a bit too much but once I started to see the patterns emerging, it just became second nature. It all clicked when I realised that a REST API is just a standardized way for programs to talk to each other over the web.

What is REST? REST (Representational State Transfer) is an architectural style that uses standard HTTP methods to perform operations on resources. It’s stateless, meaning each request contains all the information needed to process it.

HTTP Methods:

• GET: Retrieve data from the server
• POST: Create new data on the server
• PUT: Update existing data (replace entirely)
• PATCH: Partially update existing data
• DELETE: Remove data from the server

Making API Calls in JavaScript:

The Fetch API provides a clean, promise-based way to make HTTP requests:

// GET request
const response = await fetch('https://api.example.com/users');
const users = await response.json();

// POST request
const newUser = await fetch('https://api.example.com/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'John', email: 'john@example.com' })
});

Best Practices:

• Always handle errors gracefully
• Use appropriate HTTP status codes
• Implement proper authentication
• Version your APIs
• Document everything

Understanding REST APIs opens up a world of possibilities—from integrating third-party services to building your own backend systems. The ability to make API calls is fundamental to modern web development, and mastering it opens doors to countless opportunities.

From the blog BforBuild by BforBuild and used with permission of the author. All other rights reserved by the author.

When I first started learning about REST APIs, I thought it was just about how apps talk to each other over the internet. But after reading the REST API Tutorial, I realized that REST is much more than just sending HTTP requests. It’s an entire way of thinking about how systems communicate efficiently and reliably.

REST Constraints: What makes an API truly RESTful is adherence to certain constraints:

1. Client-Server Architecture: Separation of concerns between the user interface and data storage
2. Statelessness: Each request must contain all information necessary to understand and complete it
3. Cacheability: Responses must define themselves as cacheable or non-cacheable
4. Uniform Interface: A standardized way of communicating between client and server
5. Layered System: A client cannot tell whether it’s connected directly to the end server
6. Code on Demand (optional): Servers can extend client functionality by transferring executable code

Resource-Based Thinking: In REST, everything is a resource. Users, products, orders—they’re all resources identified by URIs. This mental model helps structure APIs in a logical, predictable way.

URL Design Best Practices:

• Use nouns, not verbs: /users not /getUsers
• Use plural names: /products not /product
• Use hierarchy to show relationships: /users/123/orders
• Keep URLs simple and predictable

Status Codes Matter: Using appropriate HTTP status codes helps clients understand what happened:

• 2xx: Success
• 3xx: Redirection
• 4xx: Client errors
• 5xx: Server errors

Learning REST has fundamentally changed how I think about building and consuming web services. It’s not just a technology—it’s a design philosophy that emphasizes simplicity, statelessness, and resource-based thinking.

From the blog BforBuild by BforBuild and used with permission of the author. All other rights reserved by the author.

The article explains what REST APIs are and why they are widely used. It starts by explaining the core principles of REST, such as statelessness and resource-based URIs (Uniform Resource Identifiers). In simple terms, REST APIs allow different software systems to communicate over the internet by sending requests (like GET, POST, PUT, DELETE) to a server, where each request is independent and contains all the necessary information to be processed. The article also discusses the scalability and flexibility of REST APIs, which make them a popular choice for building web applications that need to handle a large number of users or integrate with other services.

I chose this article because I’ve heard the term “REST API” thrown around in class and in tech articles, but I never fully understood how they work. As a computer science beginner, I often find myself struggling to grasp concepts like APIs and how they fit into the bigger picture of web development. Since we’re covering APIs and web services in our course, I figured reading a simple, clear article would help me solidify my understanding of this important topic.

After reading the article, I feel much more confident about my understanding of REST APIs. Before, I knew APIs were used to transfer data between different applications, but I didn’t fully understand how REST APIs specifically work. The article’s explanation of statelessness was particularly eye-opening to me. I had no idea that each request in a REST API is self-contained, meaning it doesn’t rely on any prior interactions to be processed. This makes sense when you think about how web applications need to be scalable and efficient—keeping things stateless helps ensure the server isn’t overloaded with unnecessary data.

Another thing I found interesting was the explanation of how RESTful APIs use HTTP methods (like GET and POST) to interact with resources. It made me realize how intuitive and flexible REST is for creating services that can easily be integrated with other software systems. I now feel much more comfortable working with APIs.

I want to explore more advanced topics, like authentication and error handling, which the article briefly touched on. This will help me build more secure and reliable web applications.

Resource:

https://www.cleo.com/blog/blog-knowledge-base-what-is-rest-api

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.