‹ Back to Home

What Is an API? REST, HTTP Methods, and Status Codes Explained Simply

Before wrestling with modern frameworks, learn the basic contract. Here is how clients, servers, HTTP verbs, and JSON payloads fit together in plain English.

Keerthika 8 min read
Follow on Google
Web Dev What Is an API? REST, HTTP Methods, and Status Codes Explained Simply 8 min left Follow on Google

TamilTech AI summary

  • Plain-English explanation of client-server architecture using everyday analogies
  • Clear breakdown of GET, POST, PUT, PATCH, and DELETE verbs
  • Quick-reference guide to 2xx, 3xx, 4xx, and 5xx status codes
  • Runnable code snippets in modern JavaScript and curl
  • Practical interview tips and common REST antipatterns to avoid

AI-assisted summary, checked by the TamilTech editorial team.

0:00
0:00
🔒 Listen is for subscribers. Subscribe

Key Takeaways

  • An API is simply an agreed contract: your frontend asks in a specific format, and the backend answers predictably.
  • REST uses standard HTTP verbs like GET, POST, PUT, PATCH, and DELETE to manage data without inventing custom protocols.
  • HTTP status codes tell the client the outcome instantly: 200s mean success, 400s mean the client messed up, and 500s mean the server broke.
  • JSON is the universal text format for shipping data between your browser and the server.
  • Tools like curl and Postman let you test requests directly before writing a single line of frontend UI code.

How do client and server actually talk to each other?

Picture sitting at a tea shop near Tidel Park in Chennai. You place an order with the waiter for a ginger tea. You do not march into the kitchen, light the stove, or boil the milk yourself. The waiter takes your exact order, delivers it to the kitchen counter, and brings your cup back.

In software, your browser or mobile phone is the client. The backend database holding millions of records is the kitchen. The API (Application Programming Interface) is that waiter.

An API defines a strict contract between two programs. It lays down clear rules: send data to this exact web address, use this specific format, and I will hand back the exact answer you need. When you book a train ticket on an aggregator app, the app does not hold Indian Railways seat data. It calls the IRCTC API, fetches real-time berth availability, and shows it on your screen.

REST (Representational State Transfer) is just an architectural style for organizing these rules over HTTP. It treats data items—like users, orders, or tickets—as 'resources' identified by unique web addresses (URLs). Instead of creating messy custom commands, REST relies on the standard plumbing that has powered the internet for decades.

Which HTTP methods do you really need to know?

When your client talks to a REST API, it sends an HTTP method (often called an HTTP verb) alongside the URL. This verb tells the server exactly what action you want to take on that resource.

Five standard verbs handle 99 percent of day-to-day web development:

  • GET: Retrieves data. Visiting a Flipkart product page sends a GET request to fetch product details. GET must never modify data on the server.
  • POST: Creates brand-new data. Submitting a signup form or creating a new delivery order sends a POST request with the new details tucked inside the request body.
  • PUT: Replaces an existing resource completely. If you update a profile using PUT, you send the whole profile payload, replacing whatever was there before.
  • PATCH: Updates part of an existing resource. If you only want to change your UPI payment PIN or mobile number, PATCH updates just that field without touching the rest of your account.
  • DELETE: Removes a resource. Clicking 'Remove item' in your shopping cart triggers a DELETE call targeting that specific cart item ID.

Here is how a standard JavaScript fetch call uses the POST method to create a new support ticket:

const createTicket = async () => {
  const response = await fetch('https://api.example.com/v1/tickets', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer token_abc123'
    },
    body: JSON.stringify({
      title: 'Payment failed but money debited',
      priority: 'high'
    })
  });
  const data = await response.json();
  return data;
};

What do these HTTP status codes actually tell you?

Every time an API server answers your request, it sends back a three-digit HTTP status code. Think of this code as a quick signal light before you even inspect the data.

Instead of guessing, memorize the code families by their first digit:

  • 2xx (Success): Everything went as planned. 200 OK means data was retrieved or updated successfully. 201 Created means a new resource was successfully added to the database.
  • 3xx (Redirection): The resource moved. 301 Moved Permanently tells browsers to update their bookmarks to the new URL.
  • 4xx (Client Error): You sent an invalid request. 400 Bad Request means your JSON syntax is broken or missing required fields. 401 Unauthorized means you forgot to send an authentication token. 403 Forbidden means the server knows who you are, but your role does not have permission. 404 Not Found means the requested URL or ID does not exist.
  • 5xx (Server Error): Your request was fine, but the server crashed or timed out. 500 Internal Server Error means an unhandled exception took down the backend process. 502 Bad Gateway or 503 Service Unavailable usually means the upstream service is overloaded during a flash sale.

Clean APIs return accurate status codes. If a user enters the wrong password, an API should never send back a 200 OK containing an error message inside the body. It should return a 401 Unauthorized.

How do JSON payloads carry your data?

APIs used to trade data using heavy XML files stuffed with closing tags. Today, nearly every REST API communicates using JSON (JavaScript Object Notation). It is lightweight, readable for humans, and native to every modern programming language.

JSON represents data using key-value pairs, arrays, strings, numbers, booleans, and null values. Keys must always sit inside double quotes.

Here is an example of a realistic API response payload for a food delivery order on an app like Swiggy:

{
  "order_id": "OD-98234",
  "restaurant_name": "Murugan Idli Shop",
  "total_amount_inr": 340.50,
  "is_delivered": false,
  "items": [
    {
      "item_id": 101,
      "name": "Ghee Podi Idli",
      "quantity": 2,
      "price": 140.00
    },
    {
      "item_id": 204,
      "name": "Filter Coffee",
      "quantity": 1,
      "price": 60.50
    }
  ],
  "delivery_partner": null
}

When your frontend framework fetches this response, it parses the JSON text directly into a native object. You can instantly read data.restaurant_name or iterate over the data.items array.

How can you test APIs with curl and Postman?

Never wait for a frontend interface to be built before testing your backend routes. You can test endpoints right from your command line using curl, or with a graphical tool like Postman.

curl comes pre-installed on macOS, Linux, and modern Windows terminals. It is fast, scriptable, and ideal for quick checks.

Here is how you test a public REST API endpoint directly using curl to fetch a list of posts, followed by a POST request to submit data:

1. Send a GET request to inspect headers and data
curl -i https://jsonplaceholder.typicode.com/posts/1

# 2. Send a POST request with a JSON payload and headers
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title": "My first API post", "body": "Testing REST endpoints", "userId": 1}'

If you prefer a visual interface, Postman lets you paste in the URL, pick the HTTP verb from a dropdown, add authentication headers, paste your JSON body, and hit 'Send'. You get the full response, headers, timing metrics, and status code formatted clearly on one screen.

Which common mistakes get developers into trouble?

Junior engineers often run into the same handful of API design traps:

  • Putting verbs in your URLs: In REST, URLs should name resources (nouns), not actions. Use POST /api/v1/orders, not POST /api/v1/createOrder. The HTTP method already describes the action.
  • Returning 200 OK for errors: Never return an HTTP 200 with a body like {"success": false, "error": "User not found"}. That breaks standard HTTP caching and confuses frontend interceptors. Use 404 Not Found instead.
  • Confusing 401 and 403: Use 401 Unauthorized when the client provided no credentials or invalid tokens. Use 403 Forbidden when the client is logged in, but lacks permission to view that resource.
  • Sending request bodies with GET: While technically allowed by some HTTP specs, many proxies, firewalls, and CDNs strip bodies from GET calls. Use URL query parameters for GET requests instead.

Where does this come up in Indian tech interviews?

Whether you are interviewing for a graduate trainee slot at TCS or Infosys, or targeting product firms like Zoho, Swiggy, and Razorpay, API fundamentals show up in round one. Interviewers frequently ask candidates to explain the difference between PUT and PATCH, or what status code an authentication failure should return. They will look at whether you understand idempotency—why repeating a GET or PUT multiple times produces the same server state, while repeating a POST creates duplicate records. Nailing these core fundamentals proves you understand real-world web architecture, not just framework syntax.

What is your weekend practice task?

Open your computer terminal right now and make your first real API call. Use curl to hit the free JSONPlaceholder testing service. Run a GET request to view post number 10, check the status code, and then try sending a POST request with your name as the author. Once you see a 201 Created response return in your console, you will understand how every web application on your phone actually functions under the hood.

Frequently asked questions

4

What is the difference between an API and REST?

An API is any interface that lets two software programs communicate. REST is a specific set of architectural rules for building web APIs using standard HTTP methods like GET, POST, PUT, and DELETE.

What is the difference between PUT and PATCH?

PUT replaces the entire resource with the new data you send. PATCH updates only the specific fields you provide, leaving the rest of the existing resource untouched.

Why do we use JSON instead of XML for modern APIs?

JSON is much lighter, has less syntactic clutter, and maps directly to native objects and arrays in JavaScript, Python, and other modern languages, making parsing faster and simpler.

Can a GET request have a body?

While the HTTP specification does not strictly forbid it, many web servers, load balancers, and CDNs reject or strip bodies from GET requests. Best practice is to use URL query parameters for GET requests.

Get tomorrow’s tech news on WhatsApp

One short update a day, free. Follow the TamilTech channel.

What do you think?

people reacted

Keerthika

TamilTech editorial team · 3,567 articles

Keerthika is an editor at TamilTech, the Tamil and English technology publication founded by Praveen Kumar S. She covers AI, smartphones, gadgets, EVs, startups and cybersecurity i...

More from Keerthika

Ask TamilTech on WhatsApp

Tech doubt? Ask in Tamil or English — our WhatsApp assistant answers from TamilTech articles in seconds.

Related stories

Comments (0)

| Supports **bold**, *italic*, `code`

Be the first to comment!

Next story TypeScript for JavaScript Developers: Why Every Job Post Wants It Now
Tamiltech

Tamiltech

Install app for faster access

Earn XP 🏆
WhatsApp
Notifications