REST API Explained: A Practical Guide for Beginners

REST APIs are one of the most important concepts in modern software development.

Frontend applications use APIs to communicate with backend servers. Mobile applications use APIs to retrieve and send data. Websites, dashboards, developer tools, and third-party integrations all commonly depend on APIs.

If you are learning frontend development, backend development, full-stack development, or preparing for software developer interviews, understanding REST APIs is an essential skill.

In this guide, you will learn:

• What an API is
• What REST means
• How REST APIs work
• What endpoints are
• HTTP methods
• HTTP status codes
• JSON
• Request and response structure
• CRUD operations
• Query parameters
• Path parameters
• Headers
• Authentication
• API testing
• Error handling
• CORS
• Practical JavaScript examples
• Common API mistakes
• A practical learning roadmap

1. What Is an API?

API stands for Application Programming Interface.

An API allows two different software systems to communicate with each other.

For example, imagine a frontend application that needs a list of jobs.

The frontend might send a request:

GET /api/jobs

The backend processes the request and returns data:

{
  "success": true,
  "data": [
    {
      "id": 1,
      "title": "Frontend Developer",
      "location": "Bangalore"
    },
    {
      "id": 2,
      "title": "Backend Developer",
      "location": "Hyderabad"
    }
  ]
}

The frontend can then display this information to the user.

The basic communication looks like this:

Frontend
   |
   | HTTP Request
   v
Backend API
   |
   | Database Query
   v
Database
   |
   | Data
   v
Backend API
   |
   | HTTP Response
   v
Frontend

An API acts as the communication layer between applications.

2. What Is REST?

REST stands for:

Representational State Transfer

REST is an architectural style used to design network-based applications.

A RESTful API commonly uses:

• HTTP
• URLs
• Resources
• HTTP methods
• JSON
• HTTP status codes

For example:

GET    /api/jobs
GET    /api/jobs/101
POST   /api/jobs
PUT    /api/jobs/101
DELETE /api/jobs/101

Here, jobs represents a resource.

3. How a REST API Works

A typical REST API interaction looks like this:

The client can be:

• Web browser
• React application
• Mobile application
• Desktop application
• Another server
• API testing tool

The API receives the request, performs the required operation, and sends a response.

4. API Endpoints

An endpoint is a URL where a particular API resource or operation can be accessed.

Example:

https://example.com/api/jobs

A common API structure might look like:

/api/users
/api/users/101

/api/jobs
/api/jobs/501

/api/posts
/api/posts/25

/api/comments
/api/comments/100

The number often identifies a specific resource.

For example:

/api/jobs/501

means:

Get the job whose ID is 501.

5. HTTP Methods

REST APIs commonly use HTTP methods to describe what operation should be performed.

The most important methods are:

6. GET

GET is used to retrieve information.

Example:

GET /api/jobs

This could return all jobs.

To retrieve one job:

GET /api/jobs/501

Example response:

{
  "id": 501,
  "title": "Frontend Developer",
  "company": "Example Company",
  "location": "Bangalore"
}

GET requests normally should not modify server-side data.

7. POST

POST is commonly used to create a new resource.

Example:

POST /api/jobs

Request body:

{
  "title": "Frontend Developer",
  "company": "Example Company",
  "location": "Bangalore"
}

The server may create the new job and return:

{
  "success": true,
  "data": {
    "id": 502,
    "title": "Frontend Developer",
    "company": "Example Company",
    "location": "Bangalore"
  }
}

8. PUT

PUT is generally used when replacing or updating an existing resource.

Example:

PUT /api/jobs/502

Request:

{
  "title": "Senior Frontend Developer",
  "company": "Example Company",
  "location": "Bangalore"
}

The server updates the resource.

9. PATCH

PATCH is commonly used for a partial update.

For example, if you only want to change the location:

PATCH /api/jobs/502

Request body:

{
  "location": "Hyderabad"
}

Unlike a full replacement, PATCH can update only the required fields.

10. DELETE

DELETE is used to remove a resource.

Example:

DELETE /api/jobs/502

The server processes the deletion.

A successful response could be:

204 No Content

11. CRUD Operations

CRUD stands for:

• Create
• Read
• Update
• Delete

REST APIs commonly map CRUD operations to HTTP methods.

Example:

Understanding CRUD is one of the easiest ways to understand REST APIs.

12. HTTP Request Structure

An HTTP request can contain several parts.

For example:

POST /api/jobs HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer TOKEN

{
  "title": "Frontend Developer"
}

Important parts include:

• Method
• URL
• Headers
• Body

13. Request Headers

Headers provide additional information about the request.

Example:

Content-Type: application/json

This tells the server that the request body contains JSON.

Another common header is:

Authorization: Bearer YOUR_TOKEN

This can be used to authenticate the request.

Other common headers include:

Accept: application/json
Content-Type: application/json
Authorization: Bearer TOKEN

14. Request Body

The request body contains data sent to the server.

For example:

{
  "name": "Rahul",
  "email": "rahul@example.com"
}

A request body is commonly used with:

• POST
• PUT
• PATCH

For example:

POST /api/users

{
  "name": "Rahul",
  "email": "rahul@example.com"
}

15. JSON

JSON stands for:

JavaScript Object Notation

JSON is one of the most common formats used by REST APIs.

Example:

{
  "id": 101,
  "name": "Rahul",
  "role": "Frontend Developer",
  "skills": [
    "HTML",
    "CSS",
    "JavaScript"
  ]
}

JSON supports:

• Strings
• Numbers
• Booleans
• Arrays
• Objects
• null

Example:

{
  "name": "Rahul",
  "age": 24,
  "isDeveloper": true,
  "skills": ["JavaScript", "React"],
  "experience": null
}

16. API Responses

A server response usually contains:

• Status code
• Headers
• Response body

Example:

HTTP/1.1 200 OK
Content-Type: application/json

Response body:

{
  "success": true,
  "data": {
    "id": 101,
    "name": "Rahul"
  }
}

17. HTTP Status Codes

HTTP status codes tell the client what happened with the request.

2xx — Success

Common examples:

200 OK
201 Created
204 No Content

4xx — Client Error

Common examples:

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
422 Unprocessable Content
429 Too Many Requests

5xx — Server Error

Common examples:

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable

A useful mental model:

2xx → Request succeeded
4xx → Client/request problem
5xx → Server problem

18. 200 vs 201 vs 204

These status codes are often confused by beginners.

200 OK

The request succeeded.

Example:

GET /api/jobs

Response:

200 OK

201 Created

A new resource was successfully created.

Example:

POST /api/jobs

Response:

201 Created

204 No Content

The request succeeded but there is no response body.

Example:

DELETE /api/jobs/501

Response:

204 No Content

19. Path Parameters

Path parameters identify a specific resource.

Example:

/api/jobs/501

Here:

501

is the job ID.

Another example:

/api/users/1001

The value 1001 identifies the user.

In a backend framework, this may be represented as:

/api/jobs/:id

where :id is replaced by the actual ID.

20. Query Parameters

Query parameters are commonly used for filtering, searching, sorting, and pagination.

Example:

/api/jobs?location=Bangalore

Multiple parameters:

/api/jobs?location=Bangalore&experience=2

Search:

/api/jobs?search=frontend

Pagination:

/api/jobs?page=2&limit=20

Sorting:

/api/jobs?sort=createdAt&order=desc

21. Path Parameter vs Query Parameter

This distinction is important.

Path parameter

Used to identify a specific resource:

/api/jobs/501

Query parameter

Used to filter or modify a collection request:

/api/jobs?location=Bangalore

Think of it like this:

Specific resource
        ↓
/api/jobs/501

Filtered collection
        ↓
/api/jobs?location=Bangalore

22. Authentication

Many APIs require users to prove who they are.

Common authentication approaches include:

• Session-based authentication
• API keys
• Bearer tokens
• JWT
• OAuth 2.0

A common token-based request looks like:

GET /api/profile
Authorization: Bearer YOUR_TOKEN

The server validates the token before returning protected information.

23. Authentication vs Authorization

These concepts are different.

Authentication

Answers:

Who are you?

Authorization

Answers:

What are you allowed to do?

For example:

Login
  ↓
Authentication
  ↓
User identified
  ↓
Authorization
  ↓
Check permissions
  ↓
Allow or deny action

A normal user might be allowed to:

GET /api/jobs

but an administrator might also be allowed to:

DELETE /api/jobs/501

24. Calling an API with JavaScript

Modern JavaScript provides the fetch() API.

Example:

fetch("https://example.com/api/jobs")
  .then(response => response.json())
  .then(data => {
    console.log(data);
  })
  .catch(error => {
    console.error(error);
  });

A modern async/await version is:

async function getJobs() {
  try {
    const response = await fetch("https://example.com/api/jobs");

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

    const data = await response.json();

    console.log(data);
  } catch (error) {
    console.error("Failed to fetch jobs:", error);
  }
}

getJobs();

25. Sending POST Requests with JavaScript

Example:

async function createJob() {
  const response = await fetch("https://example.com/api/jobs", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      title: "Frontend Developer",
      location: "Bangalore"
    })
  });

  const data = await response.json();

  console.log(data);
}

The important parts are:

method: "POST"

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

and:

body: JSON.stringify({
  title: "Frontend Developer"
})

26. API Flow in a Frontend Application

A typical frontend API flow looks like this:

For example, a jobs page might:

1. Load the page.
2. Request jobs from the API.
3. Receive JSON.
4. Store the data.
5. Render job cards.
6. Show an error if the request fails.

27. API Loading States

A good frontend should handle more than just success.

There are usually at least three states:

Loading
Success
Error

Example:

let loading = true;
let jobs = [];
let error = null;

The UI could display:

Loading...

while waiting.

Then:

10 jobs found

after success.

Or:

Unable to load jobs. Please try again.

if the request fails.

28. CORS

CORS stands for:

Cross-Origin Resource Sharing

Browsers apply security rules when a frontend requests resources from another origin.

For example:

Frontend:
https://app.example.com

API:
https://api.example.com

The browser may require the API server to explicitly allow the frontend origin.

A server can return headers such as:

Access-Control-Allow-Origin: https://app.example.com

CORS is primarily a browser security mechanism.

It is not an authentication system.

29. API Testing

You do not always need a frontend application to test an API.

Popular tools include:

• Postman
• curl
• Browser DevTools
• Insomnia

For example, with curl:

curl https://example.com/api/jobs

A POST request:

curl -X POST https://example.com/api/jobs \
  -H "Content-Type: application/json" \
  -d '{"title":"Frontend Developer"}'

API testing tools allow you to inspect:

• Request URL
• HTTP method
• Headers
• Request body
• Response status
• Response body
• Response headers

30. Using Browser DevTools

When working with frontend applications, browser DevTools is extremely useful.

Open:

Browser
→ Developer Tools
→ Network

Then perform an action that calls an API.

You can inspect:

Request URL
Request Method
Status Code
Request Headers
Request Payload
Response
Response Headers

For frontend developers, learning the Network tab is a major productivity skill.

31. Common API Errors

400 Bad Request

The request is invalid.

Possible causes:

• Missing required fields
• Invalid JSON
• Incorrect parameter
• Validation failure

401 Unauthorized

The request requires valid authentication.

Possible causes:

• Missing token
• Expired token
• Invalid credentials

403 Forbidden

The server understands the request but refuses access.

For example:

Authenticated user
        ↓
Permission check
        ↓
Permission denied
        ↓
403 Forbidden

404 Not Found

The requested resource does not exist.

Example:

GET /api/jobs/999999

If that job does not exist, the server may return:

404 Not Found

500 Internal Server Error

Something went wrong on the server.

The problem may involve:

• Database errors
• Unexpected application errors
• Configuration issues
• Server-side bugs

32. API Error Responses

A good API should return useful error information.

For example:

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email is required"
  }
}

This makes it easier for frontend applications to display meaningful messages.

Avoid returning sensitive internal information such as:

Database passwords
Internal stack traces
Private tokens
Secret configuration

33. Pagination

Large datasets should usually not be returned all at once.

Instead of:

GET /api/jobs

returning thousands of jobs, an API might support:

GET /api/jobs?page=1&limit=20

Response:

{
  "data": [
    {
      "id": 1,
      "title": "Frontend Developer"
    }
  ],
  "pagination": {
    "page": 1,
    "limit": 20,
    "total": 245,
    "totalPages": 13
  }
}

Pagination improves:

• Performance
• Network usage
• Database efficiency
• User experience

34. Filtering

APIs commonly provide filtering.

Example:

/api/jobs?location=Bangalore

Multiple filters:

/api/jobs?location=Bangalore&remote=true

Experience:

/api/jobs?experienceLevel=mid

The exact parameter names depend on the API design.

35. Sorting

Sorting can be implemented with query parameters.

Example:

/api/jobs?sort=createdAt&order=desc

Another example:

/api/jobs?sort=salary&order=asc

The backend receives these parameters and determines how the results should be ordered.

36. API Versioning

APIs can change over time.

For example:

/api/v1/jobs

Later:

/api/v2/jobs

Versioning can help prevent breaking existing applications when API behavior changes.

However, API versioning strategies vary between organizations.

There is no single universal versioning approach.

37. REST API Best Practices

Use meaningful resource names

Prefer:

/api/jobs
/api/users
/api/posts

over unclear names such as:

/api/getAllJobs
/api/getUserData

The HTTP method already communicates the operation.

For example:

GET /api/jobs

is clearer than:

POST /api/getJobs

Use plural resource names consistently

A common convention is:

/api/jobs
/api/users
/api/posts

Then:

/api/jobs/501
/api/users/101
/api/posts/25

Consistency is more important than a particular naming preference.

38. Keep Responses Consistent

Suppose one endpoint returns:

{
  "data": []
}

while another returns:

{
  "results": []
}

and another returns:

{
  "items": []
}

This can make frontend development harder.

A consistent response structure is easier to work with.

For example:

{
  "success": true,
  "data": []
}

and errors:

{
  "success": false,
  "error": {
    "message": "Something went wrong"
  }
}

The exact response structure depends on the project.

39. Validate Input

Never blindly trust data received from clients.

For example:

{
  "email": "not-an-email"
}

The backend should validate the input.

Validation can check:

• Required fields
• Data types
• String length
• Email format
• Numeric ranges
• Allowed values

Validation protects data quality and improves application reliability.

40. Never Trust the Client

A frontend may send:

{
  "role": "admin"
}

That does not mean the user should become an administrator.

The backend must enforce permissions.

Remember:

Frontend validation
        ≠
Backend security

Frontend validation improves user experience.

Backend validation and authorization protect the application.

41. REST API Security Basics

When building APIs:

• Use HTTPS
• Validate input
• Authenticate protected endpoints
• Authorize sensitive operations
• Protect secrets
• Avoid exposing sensitive data
• Rate-limit where appropriate
• Handle errors safely
• Keep dependencies updated

Never place secret API keys directly in public frontend code unless the key is specifically designed to be public.

42. A Simple REST API Architecture

A backend application may be organized like this:

A simplified responsibility model:

Router
  ↓
Which endpoint?

Controller
  ↓
Handle request/response

Service
  ↓
Business logic

Database layer
  ↓
Data access

The exact architecture depends on the backend framework and project.

43. REST API Example

Imagine a simple job platform.

Get jobs

GET /api/jobs

Get one job

GET /api/jobs/501

Create a job

POST /api/jobs

{
  "title": "Frontend Developer",
  "company": "Example Company",
  "location": "Bangalore"
}

Update a job

PATCH /api/jobs/501

{
  "location": "Hyderabad"
}

Delete a job

DELETE /api/jobs/501

The complete resource flow becomes:

44. A Practical Frontend Example

Suppose your frontend displays a list of jobs.

You might create:

async function fetchJobs() {
  const response = await fetch("/api/jobs");

  if (!response.ok) {
    throw new Error("Unable to load jobs");
  }

  return response.json();
}

Then:

async function loadJobs() {
  try {
    const result = await fetchJobs();

    console.log(result.data);
  } catch (error) {
    console.error(error);
  }
}

The important pattern is:

Request
  ↓
Check response
  ↓
Parse JSON
  ↓
Use data
  ↓
Handle errors

45. Common Beginner Mistakes

Mistake 1: Confusing API with database

An API is not a database.

The API provides a communication interface.

The database stores data.

Frontend
   ↓
API
   ↓
Database

Mistake 2: Thinking GET means "database read"

GET describes an HTTP request method.

An API may perform additional backend operations while processing a GET request.

Do not think of HTTP methods as direct database commands.

Mistake 3: Ignoring status codes

Do not assume:

fetch(url)

means the request succeeded.

Always inspect:

response.ok

or:

response.status

Mistake 4: Not handling errors

A production application should handle:

Network failure
401
403
404
429
500

instead of assuming every request succeeds.

Mistake 5: Exposing secrets

Never put private server credentials into publicly accessible frontend code.

Mistake 6: Sending invalid JSON

Incorrect:

{
  "name": "Rahul",
}

Correct:

{
  "name": "Rahul"
}

JSON does not allow a trailing comma after the final property.

46. REST API Cheat Sheet

47. REST API Mental Model

A simple way to remember REST APIs is:

RESOURCE + HTTP METHOD + REQUEST + RESPONSE

For example:

RESOURCE
/api/jobs/501

METHOD
GET

REQUEST
Client asks for job 501

RESPONSE
Server returns job 501

For creating:

RESOURCE
/api/jobs

METHOD
POST

REQUEST
New job data

RESPONSE
Created job

For deleting:

RESOURCE
/api/jobs/501

METHOD
DELETE

REQUEST
Delete job 501

RESPONSE
Success / No Content

48. How to Learn REST APIs

A practical learning order is:

Step 1 — Learn HTTP

Understand:

• Request
• Response
• Headers
• Methods
• Status codes

Step 2 — Learn JSON

Practice reading and creating JSON objects.

Step 3 — Use public APIs

Make requests with:

• Browser
• curl
• Postman
• JavaScript

Step 4 — Build a CRUD API

Create something simple such as:

Todo API

with:

GET /todos
POST /todos
PATCH /todos/:id
DELETE /todos/:id

Step 5 — Connect a frontend

Build a frontend application that consumes your API.

Step 6 — Add authentication

Learn how protected endpoints work.

Step 7 — Build a complete project

For example:

Job Board
Blog Platform
Expense Tracker
Task Manager
Learning Platform

49. REST API Project Ideas

If you are learning development, try building these projects.

Beginner

• Todo API
• Notes API
• Book API
• Simple user API

Intermediate

• Job board API
• Blog API
• E-commerce API
• Expense tracker API

Advanced

• Authentication system
• Role-based access control
• Notification API
• Analytics API
• Multi-user SaaS backend

A good project should include more than just CRUD.

Try adding:

• Authentication
• Validation
• Pagination
• Filtering
• Search
• Error handling
• Authorization
• API documentation

50. What You Should Know for Developer Interviews

Interviewers may ask:

What is an API?

An API is an interface that allows software systems to communicate with each other.

What is REST?

REST is an architectural style for designing networked applications using concepts such as resources and HTTP operations.

What is the difference between PUT and PATCH?

PUT is commonly used for replacing/updating a resource, while PATCH is commonly used for partial updates.

What is the difference between 401 and 403?

401 generally indicates that authentication is required or invalid, while 403 indicates that access is forbidden.

What is JSON?

JSON is a lightweight text-based data format commonly used for exchanging structured data.

What is an endpoint?

An endpoint is a specific URL through which an API exposes a resource or operation.

What is CORS?

CORS is a browser security mechanism that controls whether cross-origin requests are allowed.

51. REST API Checklist

Before considering yourself comfortable with REST APIs, make sure you can:

• Explain what an API is
• Explain REST
• Understand HTTP requests
• Understand HTTP responses
• Use GET
• Use POST
• Use PUT
• Use PATCH
• Use DELETE
• Read JSON
• Understand headers
• Understand status codes
• Use path parameters
• Use query parameters
• Understand CRUD
• Test APIs with Postman or curl
• Use fetch() in JavaScript
• Handle API errors
• Understand authentication
• Understand authorization
• Understand basic CORS
• Build a CRUD API
• Connect an API to a frontend

52. Final Thoughts

REST APIs are a fundamental part of modern software development.

You do not need to memorize hundreds of API concepts to get started.

Focus on understanding the basic flow:

Client
  ↓
HTTP Request
  ↓
API Endpoint
  ↓
Backend Logic
  ↓
Database
  ↓
HTTP Response
  ↓
Client

Then practice by building real projects.

Start with a simple CRUD API, connect it to a frontend, add authentication, and gradually introduce pagination, filtering, validation, error handling, and authorization.

Once you understand this flow, working with frontend applications, backend services, mobile applications, and third-party APIs becomes much easier.

Learn the concepts. Build the projects. Debug real requests.

That's how REST APIs become a practical development skill.