DEV Community: Eyüp Akdeniz

HTTP & REST API Fundamentals

Eyüp Akdeniz — Sun, 18 May 2025 01:12:31 +0000

HTTP

HTTP (Hypertext Transfer Protocol) is a protocol used for exchanging data over the web.
HTTP Request is sent by a client (e.g., a web browser or mobile app) to a server, asking it to perform an operation (such as fetching or modifying data).
The client then waits for the server's HTTP Response.

Real-World Examples:

Loading product lists
Fetching user profiles
Checking order status

RESTful APIs

RESTful(Representational State Transfer) is an architectural style for designing web services (APIs).
It efficiently utilizes HTTP methods (GET, POST, PUT, DELETE, etc.) to standardize how clients interact with server resources.

Key Features:

✔ Resource-based URLs (/users, /products)

✔ Stateless (no client data stored between requests)

✔ JSON/XML responses

✔ Standard HTTP methods

REST API Best Practices

Client-Server Architecture : Backend (API) and frontend (UI) should be completely separate.

Stateless : Each request must contain all necessary authentication/authorization data.

Cacheable : Responses (especially GET requests) should be cacheable.

Uniform Interface : Resource access must follow consistent and clear rules.

Layered System : The client should never directly access the database.

HTTP Methods

Method	Purpose
`GET`	Retrieve data
`POST`	Create data
`PUT`	Full update
`PATCH`	Partial update
`DELETE`	Remove data

HTTP Status Codes

Code Range	Type	Common Codes
1xx	Informational	100 Continue
2xx	Success	200 OK, 201 Created
3xx	Redirection	301 Moved Permanently
4xx	Client Error	400 Bad Request, 404 Not Found
5xx	Server Error	500 Internal Server Error

Request Headers:

Authorization: Passes credentials for authentication.
Content-Type: Specifies the media type (MIME type) of the request body.
Accept: Specifies the media type (MIME type) of the request body.
User-Agent: Identifies the client (browser, OS, or app).

Response Headers:

Content-Type: application/json
Access-Control-Allow-Origin(CORS) : Specifies which origins are allowed to access the resource.
Instructs the client to store cookies.
Set-Cookie: Session management
Rate limiting headers:
- X-RateLimit-Limit
- X-RateLimit-Remaining
- Retry-After (on 429)

Singleton Tasarım Deseni ve Bean Scope

Eyüp Akdeniz — Sun, 15 Oct 2023 20:27:24 +0000

Singleton

Uygulamada birçok nesne tarafından yeniden kullanılması amaçlanan tek bir instance'a ihtiyaç duyulan durumlarda kullanılır. Spring'de, bu nesneleri Spring'in singleton bean'leri kullanarak veya Singleton tasarım desenini kendimiz uygulayarak oluşturabiliriz. Singleton, nesnelerin tekrar tekrar oluşturulmasının maliyetini önlemek veya bir nesneyi paylaşmanın gerektiği durumlar için idealdir.

Singleton pattern implementasyonu, bir nesnenin gerçekten ihtiyaç duyulana kadar oluşturulmasını geciktirmek için genellikle tembel (lazy) başlatmayı kullanır. Yani bir nesnenin gerçekten ihtiyaç duyulana kadar oluşturulmasını erteleyerek, kaynak kullanımını ve performansı optimize edebilir.

Spring çerçevesinde bir "bean," Spring IoC konteyneri içinde oluşturulan, yönetilen ve sonlandırılan bir nesnedir.

Bean Scope

Spring bean'leri ile bir nesneyi, Inversion of Control(IoC) kullanarak, metadata aracılığıyla Spring container'ı enjekte edebiliriz. Bu, bir nesnenin bağımlılıklarını oluşturmadan tanımlayabilmesini ve bu işi IoC container'ına devredebilmesini sağlar.

Spring çerçevesinin en son sürümü altı tür kapsam tanımlar:

Singleton
Prototype
Request
Session
Application
WebSocket

Bir bean'in scope'u, yaşam döngüsünü ve görünürlüğünü tanımlar. Ayrıca bir bean'in gerçek instancelarının nasıl oluşturulacağını belirler.

Singleton Scope

Bir bean'i singleton scope ile tanımladığımızda, container o bean'in yalnızca bir instance oluşturur; bu bean adı için gelen tüm istekler aynı nesneyi döndürecektir ve bu nesne önbelleğe alınır. Nesnenin herhangi bir değişikliği, bean'e yapılan tüm isteklerde yansıtılır. Eğer başka bir kapsam belirtilmemişse, varsayılan olarak Singleton değerindedir.

Prototype Scope

Prototype scope'a sahip bir bean, her seferinde container istendiğinde farklı bir instance döndürecektir. Bu, bean tanımında @Scope açıklamasına prototype değerini ayarlayarak tanımlanır.

Request Scope

Bir bean, her HTTP isteği için ayrı bir instance oluşturur. Yani bir istek aldığında yanıt verilene kadar bir instance kullanılır ve yeni bir istek geldiğinde farklı bir instance bean tarafından oluşturulur. Request scope, yalnızca web uygulamaları için geçerlidir.

Session Scope

Bir bean, her HTTP oturumu için ayrı bir instance oluşturur. Bu, aynı kullanıcının oturumu boyunca aynı bean instance'ı paylaşmanızı sağlar. Session kapsamı da yalnızca web uygulamaları için geçerlidir.

Application Scope

Application kapsamı, yine yalnızca web uygulamaları için geçerlidir. Bir bean, bir ServletContext'in yaşam döngüsü boyunca aynı örneği oluşturur. Bu, tüm uygulama boyunca aynı bean instance'ı paylaşmanızı sağlar. ServletContext, bir Java web uygulamasının çalıştığı sunucu ortamında, tüm web bileşenlerinin paylaştığı bir nesnedir.

WebSocket Scope

WebSocket kapsamı da web uygulamaları ile ilişkilidir ve belirli bir WebSocket oturumu için bir bean instance oluşturur. Bu, WebSocket oturumu süresince aynı bean örneğini paylaşmanızı sağlar.

References

Inversion of Control(IoC) ve Dependency Injection(DI)

Eyüp Akdeniz — Fri, 13 Oct 2023 20:39:34 +0000

Inversion of Control (IoC)

Inversion of Control, bir nesnenin veya bir programın bölümlerinin kontrolünü ele almak yerine dışarıdan bir container veya framework tarafından sağlanan bir prensiptir. Bu prensip, yazılımın daha modüler ve esnek olmasını sağlar ve nesneler arasındaki bağımlılıkları azaltır. Genellikle nesne yönelimli programlama bağlamında kullanılır.

IoC, bir frameworkün bir programın akışını kontrol altına almasına ve özel kodumuza çağrı yapmasına olanak tanır. Bunu sağlamak için frameworkler, yerleşik ek davranışlarla birlikte soyutlamalar kullanır. Kendi davranışımızı eklemek istiyorsak, frameworkün sınıflarını genişletmemiz veya kendi sınıflarımızı eklentilememiz gerekir.

Nesneler arasındaki bağımlılıkları ortadan kaldıran ve bunun yerine soyutlamalara dayanan bir tasarım desenidir. Inversion of Control, yazılım bileşenlerini sorumluluklardan ayırmaya yönelik bir teknik olan Dependency Injection yoluyla elde edilebilir. Dependency Injection, bir sınıfın gerekli bağımlılıklarını dışarıdan enjekte etme yöntemini ifade eder. Bu da IoC prensibinin bir uygulama şeklidir ve IoC'nin bir sonucu olarak kullanılır.

IoC'nin avantajları arasında kodun daha iyi organizasyonu, test edilebilirlik ve yazılım bileşenlerinin daha kolay değiştirilebilir olması yer alır. Bu prensip, bir programın daha fazla modüler ve bakımı daha kolay hale getiren önemli bir yazılım mühendisliği ilkesidir.

Dependency Injection (DI)

Dependency Injection, bir objenin ihtiyaç duyduğu objeleri sağlar. Bağımlılıklar kendilerini oluşturmak yerine bazı dış araçlarla enjekte edilirler. Bu, kodun daha az bağımlı, daha modüler ve daha test edilebilir olmasını sağlar. Bu tasarım deseni, Inversion of Control (IoC) prensibinin bir uygulaması olarak da kabul edilir, çünkü bağımlılıkların kontrolünü sınıftan başka bir yere (çoğunlukla bir DI konteynerine veya konfigürasyon dosyasına) devreder.

Spring Boot'ta Dependency Injection için kullanılan yöntemler:

Constructor Injection
Setter Injection
Field Injection
Method Injection

References

gRPC

Eyüp Akdeniz — Wed, 04 Oct 2023 07:59:26 +0000

IDL(Interface description language)

IDL'nin temel amacı, farklı dillerde yazılmış bileşenlerin birbirleriyle etkileşimde bulunabilmelerini sağlamaktır.
Bir bileşenin sunmuş olduğu hizmetleri ve veri türlerini açıkça belirlemek, diğer bileşenlerin bu hizmetlere ve verilere erişimini kolaylaştırır.
Temel olarak, bir bileşenin veya modülün dışarıya açtığı fonksiyonların, veri yapılarının ve diğer arayüz öğelerinin nasıl görünmesi gerektiğini tanımlayan bir dil olarak düşünülebilir.
Google protocol Buffers(protobuf), Apache Thrift, Apache Avro, openAPI/swagger, WSDL, CORBA gibi teknolojiler örnek olaraka verilebilir.

Protocol Buffers

Google tarafından geliştirilen bir veri serileştirme ve iletişim biçimi formatıdır.
Protocol Buffers, hızlı, taşınabilir ve veri boyutunu minimize ederek veri alışverişini optimize eden bir veri serileştirme formatıdır.
Bu format, özellikle dil ve platform bağımsız uygulamalar arasında veri alışverişi gerektiren senaryolarda yaygın olarak kullanılır.
Protobuf, XML veya JSON gibi diğer veri serileştirme formatlarına alternatif olarak hafif ve hızlı bir yapı sunar.
Dosya uzantısı .proto formatında dır.
Şu anda protobuf dosyaları yazarken 3. versiyon kullanılır. Her .proto uzantılı dosyanın başına syntax="proto3"; eklenmesi gerekir

RPC(Remote Procedure Call)

Farklı dillerde yazılmış servislerin birbirleriyle iletişim kurmalarını kolaylaştıran yapıdır.
Servislerin güvenli, güvenilir ve etkili bir şekilde iletişim kurmalarını sağlamak bazı özellikler vardır:
- Servis Keşfi (Service Discovery): Servislerin otomatik olarak birbirlerini tespit edebilmelerini sağlar. Bu, Servislerin IP adresleri veya bağlantı noktaları gibi detayları bilmelerine gerek kalmadan birbirleriyle iletişim kurmalarını sağlar.
- Authentication: Authentication, hizmetlerin birbirlerini tanımalarını ve yetkisiz erişimi engellemelerini sağlar.
- Transport Layer Security (TLS): TLS, verilerin şifrelenerek iletilmesini sağlayan bir güvenlik protokolüdür. Bu, hizmetlerin verileri üçüncü şahısların okuyamayacağı şekilde iletmelerini sağlar.
- Retries: İletişim sırasında geçici hatalar meydana gelebilir. Eğer bir çağrı başarısız olursa, hizmetler otomatik olarak yeniden deneyebilir.
- Timeouts: Timeouts, bir çağrının belirli bir süre içinde cevap alamaması durumunda çağrının sonlandırılmasını sağlar.
- Cancellation: Client, uzun sürecek bir çağrıyı iptal etmek isteyebilir. Bu özellik, client bir çağrıyı başlatıp iptal etmesini ve hizmetin gereksiz yere kaynak kullanımını önlemesini sağlar.

gRPC

gRPC, Google tarafından geliştirilen ve açık kaynaklı bir Remote Procedure Call (RPC) framework'üdür.
Temelde, farklı dillerde yazılmış servislerin birbirleriyle iletişim kurmasını kolaylaştıran bir teknolojidir.
gRPC, Protocol Buffers (Protobuf) adı verilen bir veri serileştirme formatını temel alır ve modern dağıtık sistemlerde hızlı, verimli ve güvenilir iletişimi sağlamayı amaçlar.
Protobuf, JSON veya XML'e göre daha hafif ve verimli bir veri taşıma biçimidir.
gRPC, HTTP/2 tabanlı bir iletişim protokolünü kullanarak düşük geçikme süreleri ve yüksek veri iletim hızları sağlar. HTTP/2, tek bir bağlantı üzerinden çoklu veri akışını destekler.
gRPC, otomatikleştirilmiş yük dengeleme, zaman aşımı, hata yönetimi, güvenlik (TLS), kimlik doğrulama ve yeniden deneme gibi ortak özellikleri destekler.
gRPC, Protobuf tabanlı bir Service Definition Language kullanır. Bu dille servislerin ve mesajların tanımlanması sağlanır.
Büyük ve karmaşık sistemlerde kullanım için tasarlanmıştır. Mikro hizmet mimarileri ve bulut tabanlı uygulamalar gibi senaryolarda sıkça tercih edilir.

Protobuf

Message

Protobuf'da message, veriyi taşımak ve iletmek için kullanılan bir yapıdır.
Bu mesajlar, farklı sistemler veya bileşenler arasında veri paylaşımını kolaylaştırmak için kullanılır.
Mesajlar, sahip oldukları fields ve bu alanların veri türleri ile tanımlanır.

message ClientMsg {

string firstVar = 1;

int32 secondVar = 2;

}

message ServerMsg {

string name = 1;

int32 age = 2;

}

Service

Protobuf'da service, farklı bileşenlerin birbirleriyle iletişim kurmalarını sağlayan bir yapıdır.
Servisler, clientlara serverlara belirli işlemleri yapması için talepte bulunabildiği bir yapıdır.
RPC kavramını Protobuf'da uygulamak için servisler kullanılır.

service ServiceName {

rpc rpcCall (ClientMsg) returns (ServerMsg) {}

}

rpcCall: RPC çağrısının adıdır. Client bu adı kullanarak servera belirli bir işlem yapma talebi gönderebilir.

Stream

stream verileri Protobuf ile RPC çağrılarıyla iletmek, büyük veri miktarlarını hızlı ve etkili bir şekilde işlemek, gerçek zamanlı uygulamalarda kullanmak, enerji tasarrufu yapmak ve daha fazla senkronizasyon ve yönetim esnekliği sağlamak gibi birçok avantajı beraberinde getirir.

Server Streaming: Sunucu tarafından tek bir isteğe karşı birden fazla yanıt gönderilebilir.

rpc rpcCall (ClientMsg) returns (stream ServerMsg) {}
Client Streaming: İstemci tarafından birden fazla istek gönderilebilir ve sunucu tek bir yanıt gönderir.

rpc rpcCall (stream ClientMsg) returns (ServerMsg) {}
Bidirectional streaming: client ile server arasında chat gibi req-res gönderir.

rpc rpcCall (stream ClientMsg) returns (stream ServerMsg) {}

Not: gRPC kullanan uygulamalarda url'deki v1,v2 yani versionlama protobuf'nin değiştiği anlamına gelir.

KAFKA ve KRaft

Eyüp Akdeniz — Tue, 03 Oct 2023 11:17:42 +0000

Linkedin tarafında geliştirilmiştir. Dağıtık bir veri akış platformudur. Asenkron olarak çalışır. Kafkaya girilen mesajlar hangi formatta olursa olsun byte array halinde taşınır.

Temel Kavramlar

Topic : Gelen mesajları kategorize etmeyi sağlar. Kategorize ettiği her yapıyada partition denir.

Partition : Topic partiton'lardan oluşur. Mesajlarımız partitonlara immutable ve sıralı olarak eklenir.

Offset : Partition'lara mesajlar eklenirken artan bir id değeri ile eklenirler bu da offset denir ve partitionun kendi içinde sıralı şekilde yazılır.

Producer : Topiclere veri gönderirler. Kafka içinde hayali bir kavramdır.

Producer Acknowledgement
Mesaj teslimi üzerinde değişen düzeylerde güvenilirlik ve kontrol sağlar.

Ack 0 : Kafka brokers'a ulaşması yeter. Bu mod, en yüksek verimi ve en düşük gecikmeyi sunar, ancak mesajın Kafka'ya başarılı bir şekilde teslim edildiğini veya diğer aracılara kopyalandığını garanti etmez.
Ack 1 : Target partition'a ulaşır ve okuması beklenir. Kopyalanmayı garanti etmez.
Ack=all veya Ack=-1 : Ack 1 olacak ve replicası oluşturulacak

Consumer : Bir veya birden fazla topicten veri okur. Mesajları idlerine göre okur yani bir veri sadece bir kere okunur.

Consumer Veri Okuma Seçenekleri
At Most Once : En fazla 1 kere oku. Consumer tarafında verinin en fazla bir kez işlenmesini garanti etmez. Tüketici mesajı aldığında hemen offset'i kaydeder, bu nedenle bir hata olursa mesajı kaybetme riski vardır. Bu mod, daha hızlı işleme ve düşük maliyet sağlar, ancak veri kaybı olabilir.
At Least Once : En fazla 1 kere oku. Consumer mesajı işledikten sonra offseti kaydeder. Bazı restart durumlarında duplikasyona sebep olabilir.
Exactly Once : Tam bir kere okumadır. her mesajın en az 1 kere aktarılmasını garantiler. Transactional producer consumer kullanılır. Transactional oluğu için oldukça maliyetlidir.

Brokers : Bir cluster içinde bir veya daha fazla broker olabilir. Producerdan gelen mesajları alır, saklar ve sunmakla sorumludur.

Zookeeper
Dağıtık sistemlerin koordinasyonunu ve yönetimini sağlamak için kullanılan açık kaynaklı bir yazılım projesidir. Verilerin tutulduğu yerdir.

Zookeeper Kullanılırken Çekilen Sıkıntılar

Ölçeklendirme yaparken bottleneck olurdu.
Sınırlı sayıda partition oluşturulmasına izin verilirdi.
Kafka brokerları bir Kafka clustera katıldığında veya ayrıldığında lider seçimi süreçleri gerçekleştirilir, ve bu durum zaman zaman ZooKeeper'a ek yük getirebilir.
Kafka clusterlarının kurulması zordur ve başka componentlere bağlıdır.
Kafka cluster metadata ZooKeeper ile senkronize olabilir, ancak bazen bu senkronizasyon arızalanabilir veya out-of-sync hale gelebilir.
ZooKeeper'ın güvenlik özellikleri ve mekanizmaları, Kafka'nın güvenlik özellikleri ve gereksinimleriyle karşılaştırıldığında genellikle geride kalır.

KRaft

Kafka, Kafka 4.0 ile Zookeeper yerine KRaft'ı tamamen desteklemeye başlayacak. Quorum denetleyicileri, metadata'nın doğru bir şekilde çoğaltılmasını sağlamak için yeni KRaft protokolünü kullanır. Quorum denetleyici, iç durum makinelerinin her zaman doğru bir şekilde yeniden oluşturulabilmesini garanti eden olay kaynaklı bir depolama modeli kullanır. Bu durumu saklamak için kullanılan olay günlüğü (metadata konusu olarak da bilinir), günlüğün sonsuza kadar büyümesini engellemek için periyodik olarak kesitlerle kısaltılır. Quorum içindeki diğer denetleyiciler, aktif denetleyiciyi takip ederek, bu denetleyicinin oluşturduğu ve günlüğünde sakladığı olaylara yanıt verirler. Bu nedenle, bir düğümün, örneğin bir bölme olayı nedeniyle duraklaması durumunda, katıldığında kaçırdığı olaylara hızlı bir şekilde yetişebilmesi için günlüğe erişebilir. Bu, sisteminki kötü durum kurtarma süresini iyileştirerek önemli ölçüde azaltır.

KRaft'ın Faydaları

Kafka'nın KRaft adını alan yeni Metadata Quorum modu, ZooKeeper'ı kaldırarak Kafka'nın kendi içinde bir tür seçim (quorum) yapma yeteneği kazanmasını temsil eder. Bu mod, Kafka'nın kendi içerisinde bir seçim (quorum) mekanizması olan Raft protokolünü kullanır.
Kararlılığı artırır, yazılımı basitleştirir ve Kafka'nın izlenmesini, yönetilmesini ve desteklenmesini kolaylaştırır
Kafka'nın tüm sistem için tek bir güvenlik modeline sahip olmasını sağlar
Daha hızlı denetleyici kapatma ve kurtarma süresi
kafka single-process şekilde çalışmaya başlar.

Kafkanın Kullanım Yerleri?

Web sayfası etkinlikleri izleme
İzleme sistemlerindeki metriklerde
Log toplama sistemlerinde
Stream Proccessing işlemlerinde