URL Shortener API: katmanlı tasarım ve açık teknik sınırlar

Problem

Uzun URL'leri kısa kodlarla saklayan ve bu kodlar üzerinden asıl adrese yönlendiren küçük bir API geliştirdim. Amaç; doğrulama, veri kalıcılığı ve iş mantığını ayrı sorumluluklar olarak kurmaktı.

Kişisel katkım

.NET 8 ve ASP.NET Core ile oluşturma, sorgulama ve HTTP 302 yönlendirme uçlarını uyguladım. Domain, Application, Infrastructure ve API katmanlarını ayırdım; CQRS akışlarını MediatR ile düzenledim. PostgreSQL/EF Core, FluentValidation, xUnit/Moq testleri, Docker Compose ve yapılandırılmış loglama ekledim.

Mimari

Şema istek akışını ve katmanların sorumluluklarını gösterir.

POST /api/urls
  → API → Application: doğrulama + MediatR handler
    → Domain: URL varlığı / repository sözleşmesi
      → Infrastructure: EF Core → PostgreSQL

GET /r/{shortCode}
  → Sorgu handler'ı → kayıt varsa HTTP 302
                     kayıt yoksa HTTP 404

Bir karar ve karşılığı

URL oluşturma ve sorgulama mantığını controller'dan ayırıp handler ve repository sözleşmeleri üzerinden kurdum. Bu, iş akışını HTTP ve veri erişiminden ayrı sınamayı kolaylaştırır. Karşılığında bu boyuttaki bir API için daha fazla dosya ve bağımlılık düzeni gerekir.

Kanıt

25 Ekim 2026 kaynak incelemesi için herkese açık depo, 302 yönlendirme controller'ı ve test kaynakları incelenebilir kanıttır. Test dosyalarının varlığı güncel bir başarılı çalıştırma anlamına gelmez; bu çalışma kapsamında testler yeniden çalıştırılmadı.

Sınırlar

Canlı demo yok. Hız sınırlama anahtarı anonim isteklerde Host değerine düşer; istemci başına ayrım eksiktir. Kısa kodun önce kontrol edilip sonra kaydedilmesi, eşzamanlı isteklerin aynı kodu seçmesi riskini tek başına çözmez; kayıt çakışmasından sonra yeniden deneme eksiktir. CI kurulumu/doğrulaması tamamlanmamıştır; başarılı CI sonucu sunulmuyor. Bu açıklar burada düzeltilmedi.

Tüm projelere dön