Durum Kodu 202 Kabul Edildi Nedir? API'nin "Anlaşıldı" Yanıtı

Karmaşık bir raporu çalıştırmak için bir düğmeye tıkladınız. Ya da belki bir video dönüştürme işi talep ettiniz. Sayfanın dakikalarca donması yerine, hemen bir mesaj alırsınız: "İsteğiniz işlenmek üzere kabul edildi." Birkaç dakika sonra, tamamlanmış raporunuza bir bağlantı içeren bir e-posta alırsınız.

Bu sorunsuz, eşzamansız deneyim, iyi tasarlanmış modern yazılımların bir özelliğidir. Ve bu, kritik ancak sıklıkla yanlış anlaşılan bir HTTP durum koduyla desteklenir: 202 Accepted.

`Hemen bitti` diyen kuzeni `200 OK` veya `Yeni bir şey yaptım` diyen `201 Created`'dan farklı olarak, `202 Accepted` durum kodu tamamen beklentileri yönetmekle ilgilidir. Sunucunun "Mesaj alındı. Ne yapmam gerektiğini anladım. Sonucu size hemen veremem, ancak kuyruğa aldım ve halledeceğim. Beklemenize gerek yok." deme şeklidir.

Bu, yoğun bir restoran sahibine biletinizi vermenin dijital karşılığıdır. Size hemen yemek getirmezler, ancak sıradaki yerinizin güvende olduğuna ve yemeğinizin sonunda hazır olacağına güvenirsiniz.

Uzun süreli görevleri yöneten API'ler oluşturuyorsanız veya kullanıyorsanız, `202 Accepted`'ı anlamak, duyarlı, ölçeklenebilir ve kullanıcı dostu uygulamalar oluşturmanın anahtarıdır.

Peki, bu ne anlama geliyor ve geliştiriciler, test uzmanları ve API tüketicileri için bunu anlamak neden önemli?

Ve mekaniklere dalmadan önce, eşzamansız iş akışları gerektiren API'ler tasarlıyorsanız, bu karmaşık etkileşimleri test etmenize ve görselleştirmenize yardımcı olabilecek bir araca ihtiyacınız var. Apidog'u ücretsiz indirin; bu, `202` yanıtlarını kolayca simüle etmenize, yoklama mekanizmalarını test etmenize ve eşzamansız süreçlerinizin sağlam ve güvenilir olmasını sağlamanıza olanak tanıyan hepsi bir arada bir API platformudur.

Şimdi, `202 Accepted`'ın ne anlama geldiğini, ne zaman kullanılacağını ve doğru şekilde nasıl uygulanacağını inceleyelim.

Sahneyi Hazırlamak: Senkron Düşünmenin Sorunu

`202`'nin neden gerekli olduğunu anlamak için öncelikle senkron isteklerin sınırlamalarını kavramalıyız.

Tipik HTTP istek-yanıt döngüsü senkron ve engelleyicidir:

1. İstemci: Bir istek gönderir.
2. İstemci: Bekler... (buna genellikle "ilk bayta kadar geçen süre" veya TTFB denir).
3. Sunucu: İsteği işler (bu, karmaşık hesaplamalar, veritabanı sorguları, diğer hizmetleri çağırma gibi işlemleri içerebilir).
4. Sunucu: Bir yanıt gönderir (`200 OK`, `201 Created`, vb.).
5. İstemci: Yanıtı alır ve buna göre hareket eder.

Bu model, bir kullanıcı profilini getirme, ürün listesi alma veya tek bir alanı güncelleme gibi hızlı işlemler için mükemmel çalışır. Ancak işlem 5 saniye, 30 saniye, 5 dakika sürerse ne olur?

• Bağlantı zaman aşımına uğrayabilir, bu da hatalara yol açar.
• Kullanıcının tarayıcısı veya uygulaması donmuş gibi görünür, bu da kötü bir kullanıcı deneyimi yaratır.
• Sunucu süreçleriniz meşgul olur, diğer gelen istekleri işleyemez hale gelir, bu da zayıf ölçeklenebilirliğe yol açar.

`202 Accepted` durum kodu, bu soruna zarif bir çözümdür. HTTP'nin engelleyici doğasını kırarak eşzamansız işlemeye izin verir.

HTTP 202 Accepted Gerçekten Ne Anlama Geliyor?

HTTP `202 Accepted` durum kodu, RFC'de bir başarı yanıtı olarak tanımlanmıştır. Ancak, bu çok özel bir başarı türüdür. **202 Accepted** durum kodu, genellikle başarıyı gösteren **2xx kategorisine** aittir. Şunları belirtir:

• İstek **alındı ve anlaşıldı**.
• İstek **işlenmek üzere kabul edildi**.
• İşlem **henüz tamamlanmadı**.
• İşlem **nihayetinde tamamlanmış bir eylemle sonuçlanabilir veya sonuçlanmayabilir** (hatta daha sonra başarısız olabilir).

Ancak, isteğin başarıyla işlendiği ve tamamlandığı anlamına gelen `200 OK`'dan farklı olarak, **202 bize farklı bir şey söyler**:

Sunucu isteği kabul etti, ancak işlem henüz bitmedi.

En önemlisi, yanıt, istemciye isteğin durumunu nerede kontrol edebileceğine veya nihai sonucun gelecekte nerede mevcut olacağına dair bir ipucu vermelidir.

Başka bir deyişle, 202, sunucunun nazikçe şunu söyleme şeklidir:

"Hey, isteğini aldım. Üzerinde çalışıyorum. Ama sonucu hemen bekleme."

Bu, e-posta gönderme, büyük bir veri kümesini işleme veya bir arka plan işini başlatma gibi zaman alan **eşzamansız işlem** süreçleri için özellikle kullanışlı hale getirir.

202 Accepted Neden Var?

Tüm istekler anında işlenemez. Her API çağrısı gönderdiğinizde, sunucunun yanıt vermeden önce tüm işin tamamlanmasını beklemesi gerektiğini düşünün. Bu şunlara yol açabilir:

• Uzun süreli görevlerde **zaman aşımları**.
• İstemcilerin takılıp kalması nedeniyle **kötü kullanıcı deneyimi**.
• İşler bitene kadar kaynaklar meşgul olduğu için **sunucu aşırı yüklenmeleri**.

**202 durum kodu**, sunucuların istemcileri bekletmeden istekleri kabul etmelerine izin vererek bu sorunu çözer.

Eşzamansız İş Akışı: Adım Adım Açıklama

Somut bir örneği inceleyelim. Kişiselleştirilmiş veri raporları oluşturan bir API hayal edin.

Adım 1: İstemcinin İsteği

Bir istemci uygulaması, rapor oluşturmayı başlatmak için bir `POST` isteği gönderir.

POST /api/reports/generate HTTP/1.1Host: api.example.comContent-Type: application/jsonAuthorization: Bearer <token>
{
  "type": "annual_sales",
  "year": 2023,
  "format": "pdf"
}

Adım 2: Sunucunun 202 Yanıtı

Sunucu isteği alır. İsteğin iyi biçimlendirilmiş ve kullanıcının yetkili olduğunu doğrular. Ardından işi hemen bir işleme kuyruğuna (Redis, RabbitMQ veya Amazon SQS gibi bir sistem kullanarak) yerleştirir ve yanıt verir.

HTTP/1.1 202 AcceptedLocation: <https://api.example.com/api/reports/status/job-12345Content-Type:> application/json
{
  "message": "Your report generation request has been accepted and is being processed.",
  "job_id": "job-12345",
  "status_url": "<https://api.example.com/api/reports/status/job-12345>",
  "estimated_completion_time": "2023-10-27T10:05:00Z"
}

Bu yanıt inanılmaz derecede güçlüdür. Hadi inceleyelim:

• HTTP/1.1 202 Accepted: Ana mesaj: "Aldım."
• Location Başlığı: İsteğin durumunun izlenebileceği bir URL'yi işaret eden standart bir HTTP başlığıdır. Bu, 202 yanıtları için en iyi uygulamadır.
• Yanıt Gövdesi: Sonra ne olacağına dair faydalı, insan ve makine tarafından okunabilir bilgiler sağlar. `job_id` ve `status_url` çok önemlidir.

Adım 3: Eşzamansız İşleme

İstemci artık başka şeyler yapmakta özgürdür. Bu arada, sunucuda:

• Ayrı bir arka plan çalışanı (veya süreç) işi kuyruktan alır.
• Zaman alıcı görevi gerçekleştirir: veritabanını sorgulama, veri derleme, PDF oluşturma.
• Tamamlandığında, sonucu depolar (örn. S3 gibi bulut depolamada) ve iş durumunu "tamamlandı" olarak günceller.

Adım 4: İstemci Tamamlanmayı Kontrol Eder

İstemci artık 202 yanıtında sağlanan `status_url`'yi yoklayabilir.

GET https://api.example.com/api/reports/status/job-12345

Bu yoklama isteğine verilen yanıt zamanla değişebilir:

• Başlangıçta: {"status": "processing", "progress": 45}
• Tamamlandığında: {"status": "completed", "download_url": "<https://api.example.com/api/reports/download/job-12345.pdf>"}

Alternatif olarak, sunucu, istemci tarafından sağlanan bir URL'ye **webhook** aracılığıyla bir bildirim gönderebilir; bu, yoklamadan daha gelişmiş ve verimli bir yöntemdir.

202 Accepted'ın Temel Özellikleri

İşte bir 202 yanıtının temel özellikleri:

• İstek alındı: Sunucu isteğinizi aldı.
• İşlem tamamlanmadı: Gerçek iş hala devam ediyor.
• Tamamlanma garantisi yok: 200'den farklı olarak, 202 işin başarılı olacağını garanti etmez, sadece kabul edildiğini belirtir.
• Eşzamansız iş akışları için kullanışlı: Arka plan işleri, kuyruklar veya gecikmeli işleme.

202 Accepted ve Diğer Başarı Kodları: Farkı Bilmek

`202`'yi diğer 2xx kodlarıyla karıştırmak kolaydır. İşte basit bir kopya kağıdı:

• 200 OK: "İsteğinizi başarıyla işledim *ve* sonuç *hemen burada*." (Senkron, anında sonuç)
• 201 Created: "Hemen *yeni bir kaynak oluşturdum*. İşte konumu ve verileri." (Senkron, anında oluşturma)
• 202 Accepted: "İsteğinizi işleyeceğim. Sonuç için daha sonra tekrar kontrol edin." (Eşzamansız, ertelenmiş işleme)
• 204 No Content: "İsteğinizi başarıyla işledim, ancak size geri gönderecek içeriğim yok." (Senkron, gövdesiz)

Sonuç hemen değil, gelecekte mevcut olacağında `202`'yi kullanın.

Neden 202 Accepted Kullanılmalı? Temel Faydaları

1. Gelişmiş Kullanıcı Deneyimi (UX): İstemci uygulaması duyarlı kalır. Kullanıcılar, isteklerinin alındığına dair anında geri bildirim alır, dönen bir ölüm çarkı değil.
2. Daha İyi Sunucu Ölçeklenebilirliği: Sunucunun ana istek işleme iş parçacıkları neredeyse anında serbest kalır. Ağır işleri arka plan çalışanlarına devrederek sunucunun çok daha fazla gelen isteği işlemesine olanak tanır.
3. Belirsizliği Yönetir: Sunucu, daha sonra yerine getirilebileceğinden %100 emin olmasa bile bir isteği kabul edebilir. Örneğin, geçici olarak kapalı olan üçüncü taraf bir hizmete bağlı bir isteği kabul edebilir.
4. Karmaşık İşlemler İçin Gerçekçi: E-posta gönderme, video işleme, makine öğrenimi modellerini çalıştırma veya büyük veri dışa aktarımlarını yönetme gibi zaman alan gerçek dünya süreçlerini doğru bir şekilde modeller.

HTTP 202 İçin Gerçek Dünya Kullanım Durumları

Birçok modern uygulamada `202 Accepted` ile karşılaşacaksınız:

• Dosya İşleme: Resim/video dönüştürme, belge dönüştürme (örn. PDF oluşturma).
• Veri İşlemleri: Büyük rapor oluşturma, veri dışa aktarma/içe aktarma, toplu e-posta gönderimleri.
• Yapay Zeka/Makine Öğrenimi: Model eğitimi veya çıkarım için bir görev gönderme.
• Ödeme İşleme: Bazı ödeme ağ geçitleri bir ödeme isteğini eşzamansız olarak kabul eder.
• DevOps/CI-CD: Bir derleme hattını tetikleme. API isteği hemen kabul eder ve derleme günlüklerine bir bağlantı döndürür.

202 Accepted Kullanmanın Faydaları

Geliştiriciler ve API tasarımcıları neden 202 kullanmalı?

1. İstemci zaman aşımlarını önler: Kullanıcıların beklemesi gerekmez.
2. Ölçeklenebilirliği artırır: Sunucular uzun görevlerde kilitlenmez.
3. Daha iyi kullanıcı geri bildirimi: Sessizlik yerine, istemciler isteğin işlendiğini bilir.
4. Eşzamansız mimarileri destekler: Modern mikro hizmetler için esastır.

Eşzamansız İş Akışlarında 202 Accepted

İşte tipik olarak nasıl çalıştığı:

1. İstemci bir istek gönderir.
2. Sunucu 202 ile yanıt verir ve muhtemelen bir "durum URL'si" sağlar.
3. İstemci, işin bitip bitmediğini görmek için durum uç noktasını tekrar kontrol eder.

Örneğin:

{
  "status": "processing",
  "check_status": "/jobs/12345/status"
}

Bu desen her iki tarafı da mutlu eder: istemci anında onay alır ve sunucu nefes alma alanı bulur.

Apidog ile 202 İş Akışlarını Test Etme

Eşzamansız bir API akışını test etmek, basit bir senkron çağrıyı test etmekten daha karmaşıktır. İşte Apidog'un paha biçilmez bir araç haline geldiği nokta.

1. Akışı Betikleme: İlk olarak `POST` isteğini gönderen ve `status_url` ile bir `202` döndürdüğünü doğrulayan bir test senaryosu oluşturun.
2. Değişkenleri Çıkarma: Apidog'un betikleme özelliğini kullanarak `job_id` veya `status_url`'yi `202` yanıtından otomatik olarak çıkarın ve bir ortam değişkeni olarak kaydedin.
3. Yoklamayı Test Etme: Çıkarılan değişkeni kullanarak `status_url`'yi çağıran sonraki bir `GET` isteği oluşturun. Apidog'u, "tamamlandı" durumu alana kadar bu isteği yeniden deneyecek şekilde yapılandırabilirsiniz.
4. Nihai Sonucu Doğrulama: İş tamamlandığında, indirme URL'sinden gelen nihai yanıtı doğrulamak için iddialar yazın.

Bu, tüm eşzamansız yolculuğun testini otomatikleştirmenize, güvenilirliği sağlamanıza ve regresyonları yakalamanıza olanak tanır.

202 Accepted Yanıtları Nasıl Test Edilir (Apidog ile)

İşte **Apidog**'un parladığı nokta. Statik araçların aksine, Apidog size şunları sağlar:

• İstekler gönderin ve farklı durum kodlarını (202 gibi) simüle edin.
• Eşzamansız iş akışlarını test etmek için **API uç noktalarını taklit edin**.
• Geliştiricilerin 202 yanıtından ne bekleyeceklerini bilmeleri için **API'leri belgeleyin**.
• Eşzamansız işlemeyi iyileştirmek için ekip üyeleriyle **işbirliği yapın**.

Apidog ile, kabulden tamamlanmaya kadar **uçtan uca 202 iş akışlarını** araç değiştirmeden oluşturabilir ve test edebilirsiniz.

Potansiyel Tuzaklar ve Yaygın Yanlış Anlamalar

Bununla birlikte, 202 yanlış kullanılabilir. Bazı tuzaklar şunları içerir:

• Tamamlanmayı varsaymak: İsteğin kabul edilmiş olması, başarılı olduğu anlamına gelmez.
• Takip sağlamamak: API'ler, istemcilerin iş durumunu kontrol etmeleri için yollar içermelidir.
• 202'yi aşırı kullanmak: Basit, anlık işlemler için kullanmayın; bu, istemcileri karıştıracaktır.

Zorluklar ve En İyi Uygulamalar

`202`'yi doğru bir şekilde uygulamak dikkatli düşünmeyi gerektirir.

1. Bir Durum Uç Noktası Sağlayın: Bu tartışılamaz. İstemcinin isteğin ilerlemesini ve nihai sonucunu kontrol edebileceği bir URL'yi (`Location` başlığı veya yanıt gövdesi aracılığıyla) **sağlamalısınız**.
2. İdempotans Çok Önemlidir: Bir istemci isteğinin geçip geçmediğinden emin değilse (örn. bir ağ sorunu nedeniyle), yeniden deneyebilir. API'niz, aynı işin birden çok kez kuyruğa alınmasını önlemek için **idempotans anahtarları** kullanarak yinelenen istekleri sorunsuz bir şekilde ele alacak şekilde tasarlanmalıdır.
3. Net Beklentiler Belirleyin: Yanıt gövdesini, tahmini tamamlanma süresi veya basit bir durum mesajı (`queued`, `processing`, `failed`, `succeeded`) vermek için kullanın.
4. Webhook'ları Düşünün: Yoklamaya daha verimli bir alternatif olarak, istemcilerin iş tamamlandığında sunucunuzun çağıracağı bir webhook URL'si kaydetmelerine izin verin.
5. Başarısızlığı Planlayın: İş arka planda başarısız olabilir. Durum uç noktanızın başarısızlıkları bildirmesi ve potansiyel olarak neden kodları sağlaması gerekir.

202 Accepted Uygulamak İçin En İyi Uygulamalar

202 döndüren API'ler tasarlıyorsanız, bu en iyi uygulamaları aklınızda bulundurun:

• Her zaman bağlam döndürün: Bir iş kimliği veya durum URL'si sağlayın.
• Açıkça belgeleyin: İstemcilerin ilerlemeyi nasıl kontrol etmesi gerektiğini açıklayın.
• Mümkün olduğunda webhook kullanın: Görevler bittiğinde istemcileri bilgilendirin.
• Aşırı kullanmayın: Yalnızca gerçekten eşzamansız görevler için 202 döndürün.

REST ve GraphQL API'lerinde 202 Accepted

• REST API'leri: İstekler genellikle uzun süreli süreçlere karşılık geldiği için 202 yaygındır.
• GraphQL API'leri: GraphQL senkron sorguları tercih ettiğinden daha az yaygındır, ancak eşzamansız mutasyonlarla yine de mümkündür.

Sonuç: Eşzamansız Tasarımı Benimsemek

HTTP `202 Accepted` Durum kodu, API tasarımcısının araç setinde güçlü bir araçtır. API'leri basit istek-yanıt mekanizmaları olarak düşünmekten, onları karmaşık, gerçek dünya iş akışlarını düzenleyen sistemler olarak düşünmeye bir geçişi temsil eder. 202 Accepted durum kodu en ünlü HTTP kodu olmayabilir, ancak eşzamansız API iş akışlarında kritik bir rol oynar. İstemcilere, "İsteğinizi aldık, ancak hala üzerinde çalışıyoruz." der.

`202` kullanarak, daha ölçeklenebilir, daha dayanıklı ve onları kullanan geliştiriciler ile nihayetinde onlardan faydalanan son kullanıcılar için çok daha üstün bir deneyim sunan API'ler oluşturursunuz.

Yazılımda her şeyin anında gerçekleşmediğini kabul eder ve bu gerçeği ele almak için standartlaştırılmış, sağlam bir yol sağlar.

Bu nedenle, uzun süreli bir görev için bir uç nokta tasarlarken, onu senkron olmaya zorlamayın. Görevin eşzamansız doğasını benimseyin. Bir `202 Accepted` döndürün, bir durum URL'si sağlayın ve uygulamanızı bekleyen isteğin zorbalığından kurtarın. 202 döndüren API'ler oluşturuyor veya test ediyorsanız, bu iş akışlarını sorunsuz bir şekilde simüle etmenize, test etmenize ve belgelemenize olanak tanıyan araçlara ihtiyacınız var. Apidog tam olarak bunu sunar. Uygulamanızın sağlam, test edilebilir ve entegre edilmesi keyifli olduğundan emin olmak için Apidog gibi bir araç kullanın. API testinizi ve belgelemenizi basitleştirmeye hazır mısınız? Apidog'u bugün ücretsiz indirin ve 202 Accepted gibi kodları yönetmeyi zahmetsiz hale getirin.