🌐 REST API — More Than Just GET, POST, PUT & DELETE

As a backend developer, we hear about REST APIs almost every day.

But what exactly is REST?

What is an API?
And what is the philosophy behind REST API design?
Today, I’m trying to understand these concepts step by step.

1. What is REST? REST stands for: Representational State Transfer.

REST is not a programming language, framework, or protocol.
It is an architectural style for designing networked applications.

In simple terms, we can think of REST as:

An architectural approach to organizing data and information as resources, representing them in a meaningful way, and transferring those representations through a uniform interface.

For example, imagine we have a User stored in a database:
User
id: 10
name: Rahim
email: [e-mail]
An API can provide a representation of that resource to the client:
json
{
"id": 10,
"name": "Rahim",
"email": "[e-mail]"
}

The actual database object is not being sent directly. Instead, a representation of the resource is transferred to the client.

1. What is an API? API stands for: Application Programming Interface. Simply put, an API provides a way for different software systems to communicate with each other.

A typical flow looks like:
Client → API → Server

For example, when a frontend needs user data, it sends a request through the API.
The backend processes the request and returns a response.
Frontend → Request → Backend
Frontend ← Response ← Backend

1. What is a REST API? When an API is designed according to REST principles, we commonly call it a REST API.

For example, if we have a users resource:
http
GET /users
POST /users
GET /users/10
PATCH /users/10
DELETE /users/10
Notice something important:

1. The URL represents the resource.
2. The HTTP method represents the intended operation. For example: /users → Resource GET → Retrieve POST → Create PATCH → Update DELETE → Delete Instead of designing endpoints around actions:

/getUsers
/createUser
/deleteUser

REST encourages us to think in terms of resources.

The Philosophy Behind REST

REST is not simply about using GET, POST, PUT, PATCH, and DELETE.
The real idea is to follow a set of architectural principles when designing APIs.

1. Resource-Oriented Design
   Think about what the resource is, rather than what action you want to perform.
   The URL identifies the resource, while the HTTP method describes the interaction.

   1. Statelessness Each request should contain the information necessary for the server to process it. The server should not depend on previous requests to understand the current request. For example:

Authorization: Bearer

The authentication information is included with the request, so the server does not need to rely on the state of a previous request.

1. Client–Server Separation The client and server should have separate responsibilities.

Client → User Interface
Server → Data + Business Logic
This separation allows both sides to evolve independently.

1. Uniform Interface REST promotes a consistent and predictable way of interacting with resources.

For example:
GET /users/10

From the endpoint and method, we can understand that we are retrieving the user resource with ID 10`.

A uniform interface makes an API easier to understand, consume, and maintain.

1. Representation The server provides a representation of a resource. For example: json { "id": 10, "name": "Rahim", "email": "[e-mail]" }

JSON is commonly used for representations, but REST itself is not limited to JSON.

1. Cacheability
   Some responses can be cached when appropriate.
   Caching can reduce unnecessary requests and improve application performance.

   1. Layered System The client does not necessarily communicate directly with the main backend server.

There can be multiple layers between them:
Client
↓
Load Balancer
↓
API Gateway
↓
Backend
↓
Database
The client doesn't need to know how these internal layers are implemented.

The Key Idea

REST is not about memorizing HTTP methods.
It is a way of thinking about API design.

Think in resources, represent those resources clearly, use a uniform interface, keep communication stateless, and separate the client from the server.

Understanding this philosophy helps us move beyond simply building APIs to actually designing APIs.

I’m continuing to explore these concepts and apply them in my journey as a Go Backend Engineer.

GoLang #Golang #BackendDevelopment #RESTAPI #API #SoftwareEngineering #WebDevelopment #BackendEngineer #LearningInPublic