RESTful Architecture Nedir?

Modern yazılım dünyasında frontend – backend, mobil – server, microservice – gateway gibi kavramların merkezinde neredeyse her zaman RESTful Architecture vardır.

Ama çoğu zaman REST;

• “GET, POST kullandık → REST”
• “JSON dönüyoruz → REST”
• “API yazdık → REST”

gibi fazla yüzeysel ele alınır.

Bu yazıda REST’i:

• neden var,
• hangi problemi çözüyor,
• hangi kurallara dayanıyor,
• nasıl doğru uygulanır,
• nerelerde yanlış uygulanıyor

adım adım ele alacağız.

---

REST Ne Demek?

REST (Representational State Transfer) bir:

• framework değildir
• kütüphane değildir
• teknoloji değildir

👉 Bir mimari yaklaşımdır (architectural style)

Yani REST şunu söyler:

“Dağıtık sistemlerde, client ile server arasında nasıl bir iletişim düzeni kurmalıyız ki sistem:

• ölçeklenebilir,
• anlaşılır,
• bakımı kolay
  olsun?”

---

REST’in Çözmek İstediği Temel Problem

Şöyle düşün:

• Web sitesi var
• Mobil uygulama var
• Başka bir servis var
• Hepsi aynı backend’e bağlanıyor

Eğer:

• her client için ayrı mantık,
• ayrı endpoint davranışı,
• ayrı state yönetimi

yaparsan → sistem kısa sürede kontrolden çıkar.

REST burada şunu der:

“Client ile server arasında net, sade ve kurallı bir sözleşme yap.”

---

REST’in 6 Temel İlkesi (Kalbi Burada Atıyor)

Bir API’ye “RESTful” diyebilmek için bu prensiplerin büyük çoğunluğunu uyguluyor olman gerekir.

---

Client – Server Ayrımı

Ne demek bu?

Client:

• UI’dan sorumlu
• Kullanıcı deneyiminden sorumlu

Server:

• iş kurallarından sorumlu
• veriden sorumlu

👉 Birbirlerinin iç işleyişini bilmezler.

Sözlü anlatım

“Frontend değişse bile backend bozulmamalı.
Backend refactor edilse bile frontend çökmemeli.”

Örnek

• Frontend: React → Flutter’a geçtin
• Backend: Aynı REST API çalışmaya devam eder

Bu = loosely coupled sistem

---

Stateless (Durumsuzluk)

REST’in en kritik kuralı

Server client’ı hatırlamaz.

Her istek:

• kim olduğunu
• ne istediğini
• yetkisini

kendi içinde taşır.

Yanlış düşünce

“Ama login olduk, server biliyor.”

❌ Hayır.
Server session tutmaz (REST’te).

Doğru yaklaşım

GET /orders
Authorization: Bearer eyJhbGciOi...

Server şunu yapar:

• Token’ı okur
• Yetkiyi çözer
• Cevap döner
• Unutur

Avantajı ne?

• Load balancer arkası çok rahat
• Yatay ölçekleme kolay
• Failover problemsiz

---

Resource (Kaynak) Odaklı Tasarım

REST’te fiiller değil, isimler konuşur.

Yanlış API

GET /getUser
POST /createUser
POST /updateUser

Doğru REST yaklaşımı

GET    /users
POST   /users
GET    /users/42
PUT    /users/42
DELETE /users/42

👉 Ne? → URL
👉 Ne yapayım? → HTTP Method

---

HTTP Method’ların Anlamına Sadık Kalmak

REST’in HTTP ile bu kadar güçlü olmasının sebebi bu.

Method	Anlamı
GET	Oku
POST	Yeni oluştur
PUT	Tam güncelle
PATCH	Kısmi güncelle
DELETE	Sil

Örnek

PUT /users/42

“42 numaralı user’ın tamamını güncelliyorum”

PATCH /users/42

“42 numaralı user’ın sadece bazı alanlarını değiştiriyorum”

---

Representation

Client, kaynağın kendisiyle değil,
temsil edilen haliyle ilgilenir.

Genelde bu temsil:

• JSON
• XML (artık nadir)

Örnek Response

{
  "id": 42,
  "name": "Eray",
  "email": "eray@example.com"
}

Client şunu bilir:

• Alanlar
• Tipler
• Format

Ama veritabanı yapısını bilmez.

---

Uniform Interface (Tek Tip Arayüz)

REST şunu ister:

“Tüm API’ler aynı mantıkla çalışsın.”

Yani:

• aynı isimlendirme
• aynı hata formatı
• aynı response yapısı

Örnek hata standardı

{
  "error": "ValidationError",
  "message": "Email is required"
}

Frontend her endpoint için:

• farklı hata çözmek zorunda kalmaz

---

RESTful Endpoint Tasarımı – Gerçekçi Örnek

Senaryo: Blog Sistemi

Kaynaklar

• users
• posts
• comments

Endpoint’ler

GET    /posts
POST   /posts
GET    /posts/{id}
PUT    /posts/{id}
DELETE /posts/{id}

GET    /posts/{id}/comments
POST   /posts/{id}/comments

Okunabilirlik

“Post’un comment’lerini getir”

URL’den konuşur gibi anlaşılıyor.

---

REST’te Status Code Kullanımı (Çok Hafife Alınıyor)

Status code’lar client ile server arasındaki dil gibidir.

Kod	Anlam
200	Başarılı
201	Oluşturuldu
400	Client hatası
401	Yetkisiz
403	Yasak
404	Bulunamadı
500	Server hatası

Örnek

POST /users
→ 201 Created

GET /users/999
→ 404 Not Found

---

REST Nerede Yanlış Uygulanıyor?

En sık hatalar:

• Her şeyi POST yapmak
• /doSomething tarzı endpoint’ler
• Session kullanmak
• HTTP status code yerine her şeyi 200 OK dönmek
• Resource yerine action odaklı URL’ler

---

REST Ne Zaman Yeterli Olmaz?

REST:

• CRUD ağırlıklı
• standart veri erişimi

için çok güçlüdür.

Ama:

• çok karmaşık query’ler
• client’a özel veri şekilleri
• real-time ihtiyaçlar

varsa:

• GraphQL
• gRPC
• WebSocket

gibi alternatifler düşünülür.

---

Kapanış – REST’i Doğru Anlamak

REST:

• “API yazmak” değildir
• “JSON dönmek” değildir

REST:

• disiplin
• sözleşme
• uzun vadeli sürdürülebilirliktir

Eğer REST’i doğru uygularsan:

• frontend daha hızlı gelişir
• backend daha az kırılır
• sistem büyüdükçe karmaşa artmaz

Kaynakça:

• https://www.opc-router.com/what-is-rest/