DEV Community: Ajeet Verma

Why REST APIs Became So Popular

Ajeet Verma — Tue, 18 Aug 2026 04:55:57 +0000

Almost every modern application depends on APIs.

Your mobile app talks to a backend through an API.
A React frontend communicates with a Spring Boot server through an API.
Third-party applications integrate with services through APIs.

Among the different approaches to building APIs, REST became one of the most widely adopted.

But why?

What made REST so popular?

The answer isn't simply that REST is easy to use. Its popularity comes from a combination of simplicity, scalability, flexibility, and compatibility with the web itself.

First, What Is a REST API?

REST stands for Representational State Transfer.

It isn't a programming language, framework, or protocol.

It's an architectural style for designing networked applications.

A REST API typically exposes resources through URLs and uses standard HTTP methods to interact with those resources.

For example:

GET    /api/users
GET    /api/users/101
POST   /api/users
PUT    /api/users/101
DELETE /api/users/101

The API represents things as resources:

/users
/products
/orders
/payments

And HTTP methods describe what we want to do with those resources.

REST Uses Something the Web Already Understands

One of REST's biggest advantages is that it builds on HTTP.

Developers don't need to learn an entirely new communication protocol.

They already understand concepts such as:

GET
POST
PUT
DELETE
200 OK
201 Created
400 Bad Request
401 Unauthorized
404 Not Found
500 Internal Server Error

REST uses these existing web standards rather than reinventing them.

That's a major reason it became so accessible.

Simple Client-Server Communication

Consider a React application requesting a user's profile.

The frontend might send:

GET /api/users/101

The backend processes the request and returns something like:

{
  "id": 101,
  "name": "Ajeet",
  "role": "Developer"
}

The frontend doesn't need to know how the backend retrieves the data.

The backend doesn't need to know how the frontend displays it.

They communicate through a well-defined interface.

This separation is one of the fundamental ideas behind REST.

JSON Made REST Even More Popular

REST APIs can return different representations, but JSON became the dominant format for modern web APIs.

Because JSON is:

Lightweight
Human-readable
Easy to generate
Easy to parse
Supported by virtually every programming language

A Java backend can communicate with a JavaScript frontend.

A Python application can communicate with a Java service.

A mobile application can communicate with a Node.js backend.

The technologies don't have to be the same.

As long as they understand HTTP and the data format, they can communicate.

REST Is Language Independent

This is another major reason for its adoption.

Imagine your backend is built with:

Java + Spring Boot
Your frontend is:
React + JavaScript

And your mobile application is:

Android

All three can communicate with the same REST API.

                 ┌── React
                 │
Client ──────────┼── Android
                 │
                 └── Another

Service
                       ↓
                 REST API
                       ↓
                  Backend

The API becomes a common communication layer between different technologies.

Statelessness: One of REST's Most Important Ideas

A REST architecture encourages stateless communication.

This means the server doesn't need to remember the client's previous request in order to understand the next one.

Each request contains the information required to process it.

For example:

GET /api/orders Authorization: Bearer <token>

The server can validate the token and process the request without depending on a specific previous request.

This makes horizontal scaling easier.

You can have:


             ┌── Server 1
Client → LB ─┼── Server 2
             └── Server 3

A request doesn't necessarily need to return to the same server that handled the previous request.

This is particularly useful in distributed and cloud-based systems.

REST and HTTP Status Codes

REST APIs also make good use of HTTP status codes.

For example:

200 OK

The request succeeded.

201 Created

A new resource was created.

400 Bad Request

The client sent an invalid request.

401 Unauthorized

Authentication is required or invalid.

404 Not Found

The requested resource doesn't exist.

500 Internal Server Error

Something went wrong on the server.

These standard status codes provide a common language between clients and servers.

REST Is Easy to Test

Because REST commonly uses HTTP, testing an API is straightforward.

You can use tools such as:

Postman
cURL
Browser developer tools
Automated API testing frameworks

For example:

https://api.example.com/users/101

You don't need a specialized client just to make a basic request.

This simplicity significantly reduces the barrier to development and debugging.

REST Fits Naturally Into Modern Architectures

REST APIs became especially important as applications moved toward:

Single Page Applications
Mobile applications
Microservices
Cloud computing
Distributed systems

A frontend and backend can evolve independently.

For example:

React
   ↓
REST API
   ↓
Spring Boot
   ↓
Database

Later, the same backend API could also serve:

React
Android
iOS
Another Backend Service
Third-Party Client

The API becomes a stable boundary between systems.

REST and Microservices

REST also played an important role in the growth of microservices.

Instead of building one massive application, functionality can be separated into different services.

For example:

Order Service
      ↓
REST API

Payment Service
      ↓
REST API

User Service
      ↓
REST API

These services can communicate over HTTP without needing to be written in the same programming language.

This flexibility helped REST become a common choice for service-to-service communication.

But REST Isn't Perfect

REST became popular, but it isn't the solution to every API problem.

Depending on the use case, other technologies may be more appropriate.

For example:

GraphQL can be useful when clients need flexible data queries.

gRPC can be useful for high-performance service-to-service communication.

WebSockets are better suited for persistent real-time communication.

Message queues are useful for asynchronous, event-driven systems.

So the question isn't:

«"Is REST better than everything else?"»

The better question is:

«"Is REST the right tool for this particular problem?"»

Why REST Ultimately Won

REST didn't become popular because it was the newest technology.

It became popular because it worked extremely well with the technologies developers were already using.

It provided:

Familiar HTTP semantics
Simple resource-based design
Language independence
Easy integration
Stateless communication
Standard status codes
Excellent tooling
Broad ecosystem support
Easy frontend and backend integration

Most importantly, REST made it relatively simple for completely different systems to communicate with each other.

The Bigger Picture

Modern software is rarely one application running on one machine.

It's usually a collection of different components:

Frontend
   ↓
API
   ↓
Backend Services
   ↓
Database
   ↓
External Services

REST provides a simple and standardized way for many of these components to communicate.

That's why, even after decades of new technologies and architectural patterns, REST APIs remain a fundamental part of modern software development.

REST didn't win because it was the most sophisticated approach.

It became popular because it made communication between systems simple, understandable, and practical.

And sometimes, simplicity is exactly what makes a technology scale.

What do you think will become the dominant API style in the next decade: REST, GraphQL, gRPC, or something else?

How Do Websites Handle Millions of Requests at the Same Time?

Ajeet Verma — Sat, 15 Aug 2026 17:29:15 +0000

Imagine opening a popular website during a major event.

Thousands—or even millions—of users may be requesting pages, loading images, submitting forms, calling APIs, and accessing data at the same time.

If all those requests were sent to a single server, the server would eventually become overloaded.

So how do large-scale applications handle this traffic?

One of the key pieces of the architecture is the Load Balancer.

The Problem: One Server Isn't Enough

Consider a simple application:

Users ↓ Application Server

Every request reaches the same server.

As traffic increases, that server has to handle more:

CPU usage
Memory consumption
Network traffic
Database connections
Concurrent requests

Eventually, the server becomes a bottleneck.

And if that server goes down, the application goes down with it.

This creates two major problems:

Scalability and availability.

The Solution: Multiple Servers

Instead of relying on one server, we can run multiple instances of the application.


             ┌── Server 1
Users → Load ├── Server 2
             ├── Server 3
             └── Server 4

Now the workload can be distributed across multiple servers.

But there's a problem.

How does the system decide which server should receive each request?

That's where the load balancer comes in.

What Is a Load Balancer?

A load balancer is a component that sits between clients and application servers.

Instead of users directly communicating with individual servers, they communicate with the load balancer.

Client
↓
Load Balancer
↓
Application Servers

The load balancer receives incoming requests and decides where each request should go.

Its job isn't simply to "split traffic."

It can also monitor server health, route requests, handle failures, and help applications scale horizontally.

How Does It Distribute Requests?

There are different load-balancing algorithms.

1. Round Robin

Requests are distributed sequentially.

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1
Request 5 → Server 2

It's simple and works well when servers have similar capacity.

2. Least Connections

The load balancer sends the request to the server currently handling the fewest active connections.

Server 1 → 100 connections
Server 2 → 45 connections
Server 3 → 70 connections

The next request would likely go to Server 2.

This can be useful when requests have different processing times.

3. Weighted Routing

Not every server necessarily has the same capacity.

For example:

Server 1 → 50%
Server 2 → 30%
Server 3 → 20%

A more powerful server can therefore receive a larger share of the traffic.

But What If a Server Crashes?

This is where load balancers become particularly valuable.

Suppose we have:

Server 1 → Healthy
Server 2 → Healthy
Server 3 → Failed

The load balancer can perform health checks on the servers.

If Server 3 stops responding correctly, the load balancer can stop sending new requests to it.

Traffic can continue through the healthy servers.


                 ┌── Server 1 ✓
Users → Load ────┼── Server 2 ✓
                 └── Server 3 ✗

The user may never know that one of the servers failed.

This improves availability and fault tolerance.

Horizontal Scaling

Load balancing becomes especially powerful when combined with horizontal scaling.

Instead of making one server increasingly powerful:

Small Server
↓
Bigger Server
↓
Even Bigger Server

we can add more servers:

Server 1
Server 2
Server 3
Server 4
Server 5

This is called horizontal scaling or scaling out.

When traffic increases, additional application instances can be added behind the load balancer.

When traffic decreases, unnecessary instances can be removed.

This approach is fundamental to many cloud-native architectures.

What Happens During a Traffic Spike?

Imagine an application normally receives:

10,000 requests per minute

Then suddenly a major event causes:

500,000 requests per minute

A single server may struggle to handle that sudden increase.

With a scalable architecture, additional application instances can be created and placed behind the load balancer.


                         ┌── Server 1
                         ├── Server 2
Users → Load Balancer ───┼── Server 3
                         ├── Server 4
                         ├── Server 5
                         └── Server 6

The load balancer distributes incoming traffic across the available instances.

This is one of the fundamental ideas behind highly scalable applications.

Is the Load Balancer the Only Thing That Makes an Application Scalable?

No.

This is an important distinction.

A load balancer can distribute traffic, but it doesn't magically make the entire application scalable.

Other components may also become bottlenecks:

Database
Cache
Message queues
External APIs
Network
Storage
Application code

For example, you could have 100 application servers but still have a database that can handle only a fraction of the traffic.

The architecture therefore needs to be designed as a complete system.

Where Does a Load Balancer Fit?

A simplified modern architecture might look like this:

Users
  ↓
DNS
  ↓
Load Balancer
  ↓
Application Servers
  ↓
Cache / Message Queue
  ↓
Database

In larger cloud-native systems, this architecture can become much more sophisticated, with components such as:

API Gateways
CDNs
Kubernetes
Service Meshes
Auto Scaling
Distributed Caches
Message Brokers
Multiple Database Instances

The load balancer is one important piece of the larger architecture.

Load Balancing Isn't Just About Performance

One common misconception is that load balancers exist only to make applications faster.

Their role is much broader.

They can help provide:

Scalability
Distribute traffic across multiple application instances.

High Availability
Continue serving requests when individual servers fail.

Fault Tolerance
Detect unhealthy instances and route traffic elsewhere.

Traffic Management
Control how requests are distributed across infrastructure.

Horizontal Scaling
Allow applications to grow by adding more instances.

The Bigger Picture

When you visit a large website, you usually don't know which physical or virtual server handled your request.

And that's exactly the point.

The infrastructure is designed so that the application can continue operating even while traffic changes, servers fail, and new instances are added.

A simple request:

User → Website

can actually travel through a much larger system:

User ↓ DNS ↓ Load Balancer ↓ Application Instance ↓ Cache / Services ↓ Database ↓ Response

The user sees a website.

Behind the scenes, an entire distributed system may be working to deliver that single response.

Final Takeaway

A load balancer isn't simply a traffic distributor.

It's an important building block for designing applications that can scale, survive failures, and handle unpredictable traffic.

The real power comes when load balancing is combined with horizontal scaling, health checks, caching, databases, auto-scaling, and resilient application design.

That's how modern systems move from:

"One server handles everything."

to:

"The system can adapt as traffic changes."

And that shift is one of the foundations of scalable software architecture.

What other system-design concept would you like to see explained this way?

About Ajeet Verma | Java Backend Developer | Spring Boot | Spring AI | Software Engineer

Ajeet Verma — Thu, 06 Aug 2026 11:20:06 +0000

If you searched for Ajeet Verma or ajeetverma01, welcome!
I'm Ajeet Verma, a Java Backend Developer passionate about building scalable enterprise applications, secure REST APIs, AI-powered solutions, and modern backend systems.
This page serves as the central hub for my technical work, projects, articles, and professional profiles across the web. Whether you're a recruiter, developer, student, or technology enthusiast, you'll find everything about my work here.

Who is Ajeet Verma?

I'm a software developer with a strong interest in backend engineering, enterprise software, and Artificial Intelligence.
My primary expertise lies in the Java ecosystem, where I build secure, scalable, and production-ready applications using modern frameworks and best engineering practices.
Beyond writing code, I enjoy understanding how technologies work under the hood and sharing that knowledge through technical writing.
This DEV profile is where I publish articles covering backend development, software engineering, Java, Spring Boot, AI, system design, Docker, and emerging technologies.

My Tech Stack

Backend

Java
Spring Boot
Spring Security
Spring AI
Hibernate / JPA
REST APIs
JWT Authentication

Frontend

React
JavaScript
HTML
CSS

Databases

PostgreSQL
MySQL

DevOps & Tools

Docker
Git
GitHub
Maven
IntelliJ IDEA
VS Code

Artificial Intelligence

Spring AI
Large Language Models (LLMs)
Retrieval-Augmented Generation (RAG)
AI Agents
Model Context Protocol (MCP )

What I Build

I enjoy building projects that solve real-world problems while following modern software engineering principles.

Some areas I frequently work on include:

Enterprise Backend Applications
Secure Authentication Systems
RESTful APIs
AI-powered Applications
Spring AI Projects
Dockerized Applications
Full-Stack Web Applications
Software Architecture
Intelligent Automation

Every project helps me improve my understanding of scalable software development and modern backend technologies.

What You'll Find on This Blog

This blog focuses on practical software engineering and enterprise development.
Topics you'll regularly see include:

Java
Spring Boot
Spring AI
Backend Development
Docker
System Design
Authentication & Authorization
Software Architecture
Artificial Intelligence
Generative AI
Large Language Models
Microservices
Cloud Technologies
Developer Productivity
Project Walkthroughs

My goal is to explain technical concepts in a practical, beginner-friendly, and industry-focused way.
Featured Projects
Some of the projects I've built include:

JWT Authentication System using Spring Boot & React
Expense & Income Tracker
Portfolio Website
Smart Shop Manager
Library Management System
College Management System

More projects are continuously being added to my GitHub.

Connect With Me

Portfolio
GitHub
LinkedIn
DEV Community
LeetCode
HackerRank
Fiverr
Instagram
Threads
Facebook
YouTube

Why I started writing?

Writing technical content helps me organize my thoughts, deepen my understanding, and contribute to the developer community.
Instead of simply documenting code, I enjoy explaining the ideas behind technologies—how they work, why they matter, and where they're used in real-world software development.
Through this blog, I hope to help developers learn something new while continuing to grow as an engineer myself.

Let's Build Together

If you're interested in Java, Spring Boot, Spring AI, backend engineering, software architecture, Docker, Artificial Intelligence, or simply enjoy discussing technology, feel free to connect with me.
I'm always open to learning, collaborating, and sharing ideas with fellow developers.
Thanks for visiting my profile!
— Ajeet Verma

What Really Happens When You Click "Login"?

Ajeet Verma — Thu, 06 Aug 2026 03:55:15 +0000

The journey of a login request—from your screen to secure authentication.

Every day, millions of people click the "Login" button without giving it a second thought.

It feels like a simple action that takes just a few seconds.

But behind that single click, a series of carefully orchestrated processes work together to verify your identity, protect your credentials, and grant secure access to your account.

Let's take a look at what actually happens behind the scenes.

1. You Enter Your Credentials

It all begins when you type your email (or username) and password into the login form.

Once you click Login, your browser or mobile application doesn't verify your credentials itself. Instead, it packages the information into an HTTPS request and securely sends it to the backend server.

HTTPS encrypts the data while it's traveling across the internet, ensuring that sensitive information can't be easily intercepted.

2. The Backend Receives the Request

The server receives the authentication request and begins processing it.

Before anything else, it validates the incoming data:

Are the required fields present?
Is the email formatted correctly?
Does the request meet security and validation rules?

Only after passing these checks does the authentication process continue.

3. The Server Looks Up Your Account

The backend queries the database using your email or username.

If no matching account exists, the server immediately returns an authentication failure.

If the account exists, the server retrieves the stored user information—including the hashed password, not the original password.

This is an important security principle:

Well-designed applications never store plain-text passwords.

Instead, passwords are transformed into irreversible hashes using algorithms like BCrypt or Argon2.

4. Password Verification

Many people think the server decrypts your password.

It doesn't.

The password you entered is hashed using the same algorithm and compared against the stored hash.

If both hashes match, your identity is verified.

If they don't, access is denied.

This process allows applications to verify passwords without ever knowing or storing the original password.

5. Authentication Token Is Generated

Once authentication succeeds, the server generates an authentication token.

In many modern applications, this is a JWT (JSON Web Token).

Some applications also issue:

An Access Token for API requests.

A Refresh Token to obtain new access tokens without asking users to log in again.

These tokens represent your authenticated session.

6. The Client Stores the Token
The frontend receives the token and stores it securely.

Depending on the application's architecture, it may be stored in:

HttpOnly Cookies
Secure Cookies
Browser Storage
Mobile Secure Storage

Security practices differ depending on the application's requirements.

7. Every Future Request Includes the Token

After logging in, you don't send your password with every request.

Instead, each API request includes the authentication token.

The backend validates the token before allowing access to protected resources.

If the token is valid, the request proceeds.

If the token has expired or has been tampered with, the request is rejected.

This enables modern applications to remain stateless, scalable, and secure.

Why This Matters
A login system isn't simply checking whether a password is correct.

It's establishing trust between a user and an application while protecting sensitive information at every step.

Behind a single click lies encryption, password hashing, database lookups, authentication, token generation, session management, and multiple security checks—all designed to provide a seamless and secure user experience.

The next time you click "Login," remember that your application has already completed a sophisticated authentication workflow in just a few milliseconds.

Authentication is one of those features users rarely notice—until it fails.

Which part of the login process do you find most interesting: password hashing, JWT authentication, or token-based authorization?

Why AI Hallucinates: Think of It Like a GPS with an Outdated Map

Ajeet Verma — Mon, 03 Aug 2026 03:27:28 +0000

Artificial Intelligence has become incredibly powerful, but one question continues to puzzle many people:
"Why does AI sometimes give completely wrong answers with so much confidence?"
The answer becomes much easier when you think of AI as a GPS with an outdated map.
Imagine you're driving to a destination using GPS. Most of the roads on the map are accurate, and the navigation works perfectly. But suddenly, you reach an area where the map hasn't been updated.
Instead of saying,
"I don't know this route."
the GPS calculates what it believes is the most likely path based on the available information.
It confidently tells you to turn left...
...only for you to discover that the road no longer exists.
That's remarkably similar to how AI hallucinations occur.
Large Language Models (LLMs) don't search the internet every time you ask a question, nor do they reason like humans. They generate responses by predicting the most probable sequence of words based on patterns learned from massive amounts of training data.
Most of the time, those predictions are accurate.
However, when the model encounters incomplete information, ambiguous prompts, or topics outside its knowledge, it may generate an answer that is:
✔ Grammatically correct
✔ Logically structured
✔ Highly convincing
...but factually incorrect.
This phenomenon is known as an AI hallucination.
The important thing to understand is that AI isn't intentionally making things up. It isn't trying to deceive anyone.
It's simply predicting what is most likely to come next—not verifying whether the information is actually true.
This is exactly why modern AI systems are increasingly combined with technologies such as Retrieval-Augmented Generation (RAG), tool calling, knowledge bases, and real-time search. These approaches allow AI to retrieve reliable information before generating a response, significantly reducing hallucinations and improving accuracy.
As AI becomes part of enterprise software, healthcare, finance, education, and countless other industries, understanding its limitations is just as important as understanding its capabilities.
The biggest lesson?
Confidence is not the same as correctness.
Just because an AI sounds certain doesn't mean the answer is true—just like a GPS can confidently guide you toward a road that no longer exists.
The future of AI isn't just about making models smarter.
It's about making them more reliable, verifiable, and trustworthy.

Understanding AI hallucinations isn't just important for AI engineers—it's becoming essential for every developer, business, and user interacting with AI.
As AI becomes integrated into enterprise applications, customer support, healthcare, finance, and education, the focus is no longer just on generating intelligent responses. The real challenge is ensuring those responses are accurate, trustworthy, and grounded in reliable information.
That's why modern AI systems increasingly rely on techniques such as Retrieval-Augmented Generation (RAG), tool calling, knowledge bases, and real-time data retrieval. These approaches don't just make AI smarter—they make it more dependable.
The future of AI isn't about building models that always have an answer.
It's about building systems that know when to answer, when to retrieve information, and when to say, "I don't know."
Because in AI, confidence is easy to generate—but trust has to be earned.

--By Ajeet Verma(Java full stack developer)

What analogy would you use to explain AI hallucinations to someone new to AI?

Why Docker Has Become a Standard Tool for Developers

Ajeet Verma — Fri, 31 Jul 2026 09:17:54 +0000

Modern software development is no longer just about writing code—it's about ensuring that code runs consistently across every environment.

For years, one of the biggest challenges developers faced was the classic:

«"It works on my machine."»

Docker fundamentally changed that.

By packaging an application with its runtime, dependencies, libraries, and configuration into lightweight containers, Docker ensures the application behaves the same whether it's running on a developer's laptop, a testing environment, or a production server.

Its impact goes far beyond containerization.

✔ Consistent development environments
✔ Faster onboarding for new developers
✔ Simplified dependency management
✔ Improved CI/CD pipelines
✔ Efficient resource utilization compared to traditional virtual machines
✔ Seamless deployment across cloud and on-premise infrastructure

Today, Docker has become a core part of the modern software development lifecycle. It's commonly used alongside technologies such as Kubernetes, GitHub Actions, Jenkins, and cloud platforms to build scalable, portable, and production-ready applications.

As applications continue to move toward cloud-native architectures, understanding Docker is no longer optional—it's becoming a fundamental skill for software engineers.

Docker didn't just solve deployment problems.

It standardized how modern applications are built, shipped, and deployed.

Docker #DevOps #CloudNative #SoftwareEngineering #BackendDevelopment #Java #SpringBoot #Kubernetes #CICD #Containers #DeveloperTools

Why Spring AI Could Be the Next Big Evolution of the Java Ecosystem

Ajeet Verma — Fri, 24 Jul 2026 02:57:58 +0000

Spring AI could become one of the most significant additions to the Java ecosystem in years.

The Java ecosystem has continuously evolved to meet the demands of modern software development—from enterprise applications and microservices to cloud-native architectures.

Now, the next evolution is Artificial Intelligence.

Spring AI is positioning Java to play a central role in building AI-powered enterprise applications. Rather than introducing an entirely new development model, it extends the Spring ecosystem with AI capabilities while preserving the principles that have made Spring the foundation of enterprise Java for over two decades.

This shift is important because enterprises aren't looking to replace their existing Java applications—they're looking to make them intelligent.

As organizations invest in LLMs, AI agents, RAG, and intelligent automation, frameworks that seamlessly integrate these capabilities into production systems will define the next generation of enterprise software.

Spring AI is more than a new project.

It represents the convergence of the Java ecosystem and Generative AI—bringing enterprise reliability, scalability, and developer productivity into the AI era.

The future of enterprise Java isn't just cloud-native.

It's AI-native.

SpringAI #SpringBoot #Java #JavaEcosystem #EnterpriseJava #GenerativeAI #ArtificialIntelligence #AIEngineering #SoftwareArchitecture #BackendDevelopment #LLM #Innovation

How I Built JWT Authentication in Spring Boot (Beginner-Friendly Guide)

Ajeet Verma — Thu, 23 Jul 2026 07:31:24 +0000

How I Built JWT Authentication in Spring Boot (Beginner-Friendly Guide)

Authentication is one of the first things every backend developer learns when building real-world applications.

While learning Spring Boot, I wanted to understand how secure authentication actually works, instead of simply copying code from tutorials. So I built a complete JWT Authentication system from scratch.

In this article, I'll share what I learned and how the authentication flow works.

Why JWT?

JWT (JSON Web Token) is a compact, secure way to authenticate users without storing session data on the server.

This makes applications stateless, scalable, and suitable for REST APIs.

Authentication Flow

User signs up with an email and password.
Password is securely hashed using BCrypt.
User logs in with valid credentials.
Spring Security authenticates the user.
The server generates a JWT.
The frontend stores the token.
Every protected request includes the token in the Authorization header.
A custom JWT filter validates the token before granting access.

What I Implemented

User Registration
Secure Login
Password Hashing using BCrypt
JWT Access Token Generation
Spring Security Configuration
Custom JWT Authentication Filter
Protected REST APIs
Token Validation
Exception Handling

Challenges I Faced

Like every beginner, I faced several issues:

Understanding the Spring Security filter chain
Fixing CORS errors
Handling invalid and expired tokens
Protecting APIs correctly
Learning the difference between Authentication and Authorization

Each issue helped me understand Spring Security much better.

What I Learned

Building authentication from scratch taught me much more than following tutorials.

I now have a better understanding of:

Spring Security
Stateless Authentication
JWT
BCrypt Password Encoding
REST API Security
Clean Backend Architecture

What's Next?

I'm currently building more backend projects using Spring Boot and exploring Spring AI to deepen my understanding of modern Java development.

If you have suggestions or feedback, I'd love to hear them.

Happy Coding! 🚀