[ blog · deep-dive ]7 min read

API'ler Neden Yalnızca Başarıda Ücret Almalı — HTTP 200 Faturalandırmasının Gerekçesi

Sarah ChoyYayımlanma tarihi: 3 Mayıs 20267 dk okuma

Çoğu API her faturalanabilir çağrıdan ücret alır. Yapay zekâ ajanları, kararsız upstream servislere karşı sürekli yeniden dener — bu da eski 'her zaman ücret al' modelinin aslında dayanıklılığı vergilendirdiği anlamına gelir. İşte yalnızca HTTP 200'de faturalandırmanın gerekçesi ve bunun ajan tasarlama biçiminizde neyi değiştirdiği.

Özet

•Yapay zekâ ajanları, geçici hatalarda (5xx, zaman aşımları, hız limitleri) makul biçimde yeniden dener. 'Her zaman ücret al' faturalandırması altında her yeniden deneme gerçek bir ücrettir — %99,5 çalışma süresine sahip bir upstream'i, o kötü %0,5 sırasında 5× maliyet cezasına çevirir.
•'Yalnızca HTTP 200'de ücret al', sağlayıcının teşvikini müşterinin teşvikiyle hizalar: sağlayıcılar kararsızlığı düzeltir, müşteriler bunun bedelini ödemez.
•Ayrıca tasarım kalıplarının da önünü açar — agresif yeniden deneme bütçeleri, iyimser prefetching, yedekli çağrılar — ki 'her zaman ücret al' bunları engelleyici ölçüde pahalı kılar.
•Çoğu sağlayıcı bunu yapmaz çünkü eski altyapıları ölçümlemeyi yanıta değil, upstream çağrısına bağlar. Bu, politika kılığına sokulmuş bir faturalandırma sistemi kısıtlamasıdır.

Teşvik etmeye çalıştığımız davranış

Yapay zekâ ajanları yeni bir tür API istemcisidir. Onlar, bir hatayı yakalayıp nöbetçi bir mühendise e-posta atan 2015'in dikkatli kurumsal entegrasyonları değil. Onlar, bir şey başarısız olduğunda bir süre uyuyup tekrar deneyen — bazen beş ya da on kez — ve sonucu bir insana hiç göstermeyen döngülerdir. Döngünün tüm amacı, geçici hataların son kullanıcı için görünmez olmasıdır.

Bu harika bir kalıp. Dayanıklı ürünler üretir. Açık internetin dağınık gerçekliğini kullanıcılardan gizler. Sorun şu ki API faturalandırma modeli, yeniden denemenin nadir ve varsayılan olarak caydıracak kadar pahalı olduğu bir çağda belirlendi. Hâlâ öyle çalışıyor. Bir şey döndürüp döndürmediğine bakılmaksızın her yeniden deneme faturalanabilir bir çağrıdır.

Somut olarak: %99,5 çalışma süresine sahip bir API'ye giden ve geçici hatalarda beş kez kadar yeniden deneyen bir ajan, o kötü %0,5 sırasında 5×'e kadar çağrı — ve 5× fatura — üretecektir. Ajan doğru olanı yaptı. Müşteri, upstream'in kararsızlığının bedelini öder.

Daha basit alternatif

Yalnızca HTTP 200'de ücret al. Özellikle, yalnızca belgelenmiş yanıt biçimine sahip başarılı bir yanıtta. Geri kalan her şey — çağıran hataları için 4xx, bizim hatalarımız için 5xx, zaman aşımları, hız limitleri, kısmi-ama-bozuk yanıtlar — ücretsizdir.

Bu küçük bir değişiklik gibi geliyor. Değil. İki taraf için de ekonomik olarak neyin akılcı olduğunu değiştirir:

Sağlayıcının artık kararsızlığı düzeltmek için doğrudan bir finansal teşviki vardır. Her kararsız 503, kaçırılmış bir satıştır, bedava bir öğle yemeği değil. Yalnızca-başarıda faturalandırmayı benimsemenin, güvenilirlik çalışmamızı yol haritasının tepesine çeken en büyük tek güç olduğunu gördük — o çağrılardan gelen geliri feda ederken kesinti süresini iyi gösterecek hiçbir elektronik tablo numarası yoktur.
Müşteri, yeniden deneme bütçelerini agresif biçimde boyutlandırabilir. Geçici bir hata için en kötü durum, altı çağrı (her deneme için biri ücretli) yerine tek bir ücretli çağrı (nihai başarı) olduğunda, üstel geri çekilmeli 5 yeniden denemeli bir döngü hiç düşünmeden seçilebilir.
Pazar, API'leri deneme-başına-dolar yerine başarılı-çağrı-başına-dolar üzerinden karşılaştırabilir. Doğru birim budur. İki API de '$0.001 çağrı başına' yayımlıyor ama biri %99,9 çalışma süresinde, diğeri %95'te ise, kullanıcıya görünen maliyetler 'her zaman ücret al' altında 5× farklılaşır ve 'yalnızca başarıda' altında tam olarak %0. Bir alıcının hangisini tercih etmesi gerektiği açıktır — ve 'yalnızca başarıda' bunu görünür kılar.

Ajan inşa etme biçiminizde neyin değiştiği

1. Yeniden deneme bütçeleri ücretsiz hâle gelir

'Her zaman ücret al' faturalandırması altında, geçici hata işleyicisi için doğru yeniden deneme bütçesi kabaca 1–2 denemedir — bunun ötesinde tekrarlanan hataların maliyeti önem kazanmaya başlar. 'Yalnızca başarıda' altında bütçe 'kullanıcı ne kadar bekleyebilirse o kadar'dır. Eski faturalandırma altında pervasız sayılacak 5 yeniden denemeli, üstel geri çekilmeli, jitter'lı kalıplara sahip ajan döngülerini rutin olarak görüyoruz.

2. İyimser prefetching ucuzlar

'Her zaman ücret al' altında engelleyici ölçüde pahalı bir kalıp: kullanıcı hâlâ yazarken, tahmin edilen sorgu doğruysa diye spekülatif olarak bir arama çağrısı başlatmak. Tahmin yanlışsa sonucu atarsınız. 'Yalnızca başarıda' altında bu ucuzdur çünkü iptal edilen / kullanılmayan çağrılar başarı döndürür ama siz yanıtı atarsınız — yani öngörülebilirlik ve gecikme için küçük bir prim ödersiniz. 'Her zaman ücret al' altında her yanlış tahmin ücretli bir çağrıdır, bu da bu sezgisel yöntemi sahaya sürmek için fazla pahalı kılar.

3. Yedekli çağrılar bir güvenilirlik aracına dönüşür

Bazen en ucuz güvenilirlik stratejisi, iki farklı API'ye iki istek göndermek, ilk dönen hangisiyse onu almak ve daha yavaş olanı atmaktır. 'Her zaman ücret al' altında bu faturanızı ikiye katlar. 'Yalnızca başarıda' altında atılan çağrı için ücretsizdir (yanıtı kullanmadınız, bedelini ödemediniz). Bir anda pahalı soyutlamalar olan hedging stratejileri pratik hâle gelir.

'Başarı'nın ne anlama gelmesi gerektiği

Model yalnızca 'başarı' tek anlamlıysa işler. Onu sıkıca tanımlıyoruz:

Belgelenmiş yanıt şemasıyla HTTP 200 — faturalanabilir.
Yanıt gövdesinde sarmalanmış bir hatayla HTTP 200 — faturalanabilir değil (tüm modeli bozacak açık bu olurdu).
HTTP 4xx — faturalanabilir değil. Buna 401 (auth), 402 (yetersiz kredi), 422 (doğrulama), 404 (bazı bağlamlarda bulunamadı) dahildir.
HTTP 5xx — faturalanabilir değil.
HTTP 429 (hız limiti) — faturalanabilir değil.
Bizim edge'imizden önceki ağ hataları / zaman aşımları — faturalanabilir değil.

Toplu endpoint'ler için (örn. tek bir çağrıda 25 URL içeren URL Extract), herhangi bir URL başarılı olduysa çağrının tamamı tek bir HTTP 200'dür ve URL başına ücretle faturalanır. URL başına status alanı çağırana hangi URL'lerin başarısız olduğunu söyler. İş yapıldı; faturalanabilir.

Çoğu sağlayıcı bunu neden yapmaz

Her birinin ne kadar önemli olduğuna göre sıralanmış üç neden:

Faturalandırma altyapısı. Standart kalıp, yanıt bilinmeden önce API gateway'de ölçmektir. Gateway, faturalanabilir bir olayı Kafka'ya yayar, faturalandırma sistemi onu toplar, fatura gönderilir. Ölçümlemeyi, upstream servis bir durum koduyla yanıt verdikten sonra tetiklenecek şekilde yeniden bağlamak ya (a) gateway'i backend sağlığına bağlamayı (yeni hata modları yaratarak) ya da (b) başarısız çağrıları geriye dönük olarak kredilendiren bir mutabakat hattı yazmayı gerektirir. İkisi de gerçek mühendislik işidir.
Alışkanlık. Bu kalıp güvenilir backend'ler tarafından belirlendi — Twilio, AWS, Stripe. Upstream'iniz %99,99 çalışma süresindeyken gayet iyi çalışır. LLM'leri saran, web scraping yapan ya da yavaş veri ortaklarını çağıran API'ler çok daha az güvenilirdir, ama faturalandırma kalıbı güvenilir çağdan miras kaldı ve hiç güncellenmedi.
Gelir. 'Her zaman ücret al' sadece daha fazla paradır. Çoğu sağlayıcı bu boyutta rekabet etmek zorunda kalmadı çünkü müşterilerinin çoğu ajan trafiği değildi ve senkron insan kullanıcılar ara sıra yaşanan hataları, bir faturalandırma modeli okumaya katlanmaktan daha iyi tolere eder.

İlki gerçek mühendislik. İkincisi ve üçüncüsü atalet. Ajan trafiği API tüketiminin çoğunluğu hâline geldikçe ikisi de yıkılacak — ki trend çizgileri, çoğu kamuya açık API için bunun 18 ay içinde gerçekleştiğini söylüyor.

Bir alıcı olarak nelere bakmalı

Bir ajan iş yükü için veri API'lerini değerlendiriyorsanız, üç açık soru:

'Yalnızca HTTP 200'de mi yoksa her faturalanabilir denemede mi ücret alıyorsunuz?' — net bir yanıt gerekir. 'Genellikle' ya da 'plana bağlı' kabul etmeyin.
'HTTP 207 / kısmi başarı nasıl faturalanıyor?' — açık veren yanıtı ortaya çıkarır.
'Yayımlanmış çalışma süreniz nedir ve onu tutturamazsanız SLA iade mekanizmanız nedir?' — 'yalnızca başarıda' güçlü bir sinyaldir ama gerçek bir SLA'nın yerini tutmaz. İkisi de mevcut olmalı.

Bunun işaret ettiği dönüşüm

Yapay zekâ ajanları, dokundukları her API'nin birim ekonomisini değiştirir. Ajan çağı için tasarlanmış API'ler farklı görünür — daha basit biçimler, öngörülebilir şemalar, makine dostu auth, şeffaf fiyatlandırma — ve faturalandırma modelleri de farklı görünür. 'Yalnızca başarıda' daha basit dönüşümlerden biridir. Hâlâ önümüzde olan zor olanı ise, hiçbir tarafın tüm yolun sahibi olmadığı durumda çok adımlı ajan iş akışlarının sağlayıcılar arasında nasıl fiyatlandırılacağını çözmektir.

Şimdilik, yapabildiğiniz sağlayıcılardan 'yalnızca başarıda'yı talep edin. Bundan yararlanan ajanlar inşa edin. Ve bir API satın alırken hesabı deneme-başına-dolar değil, başarılı-çağrı-başına-dolar üzerinden yapın.

Sıkça Sorulan Sorular

'Yalnızca başarıda' yaklaşımı, sağlayıcıları başarıları başarısızlık olarak yanlış sınıflandırmaya teşvik etmez mi?

Teoride evet, ama ters yöndeki baskı daha güçlüdür: geliştiriciler API'leri gerçek dünyadaki dolar-başına-yararlı-çağrı üzerinden karşılaştırır ve 'yalnızca başarıda' tam olarak bunu ölçer. Başarıları sessizce başarısızlık olarak yeniden sınıflandıran bir sağlayıcı, günler içinde öfkeli bir destek kuyruğu ve bir kamuya açık inceleme iziyle karşılaşırdı. Pazar bunun kendini düzeltecek kadar küçük.

Çağrım kısmen başarılı olursa ne olur — örneğin, 25 URL'den 2'sinin başarısız olduğu bir toplu extract?

İki makul model. (a) Herhangi bir URL başarılı olduysa çağrının tamamı HTTP 200'dür; URL başına başarısızlıklar URL başına status alanında raporlanır. İş yapıldı, yani faturalanabilir. (b) Kısmi için HTTP 207 (multi-status) — her URL ayrı ayrı faturalanır. (a)'yı seçtik çünkü fiyatlandırmayı öngörülebilir kılıyor: ajanlar başarılı bir HTTP 200'ün, en kötü durumda duyurulan kredi maliyeti olduğunu bilir. (b) daha 'adil' ama bütçelemesi daha zor.

Başarısızlık olarak ne sayılır?

Kuralımız: açıkça çağıranın hatası olan bir HTTP 4xx (bozuk gövde, eksik auth, yetersiz kredi) ücretlendirilmez. HTTP 5xx asla ücretlendirilmez — o bizim sorunumuz. Bizim tarafımızdaki ağ hataları ve zaman aşımları asla ücretlendirilmez. Hız limitleri (429) asla ücretlendirilmez. Ücretlendirilen tek şey, duyurulan yanıt biçimine sahip bir HTTP 200'dür.

Çoğu sağlayıcı neden her çağrıdan ücret alıyor?

Çoğu tarihsel olan üç neden. (1) Eski faturalandırma sistemleri, yanıt bilinmeden önce API gateway'de ölçümler. Faturalandırmayı, yanıt durumuna göre geriye dönük olarak tetiklenecek şekilde bağlamak önemsiz bir iş değil. (2) Bu kalıp, güvenilir backend'lerin olduğu bir çağda Twilio ve AWS tarafından belirlendi; LLM'leri saran ya da web scraping yapan API'ler çok daha az güvenilirdir, dolayısıyla varsayım geçerliliğini yitirir. (3) Daha fazla gelir getirir. İlk ikisi bahane; üçüncüsü gerçek.

'Her zaman ücret al' yaklaşımının mantıklı olduğu durumlar var mı?

Çağrı, sonuç ne olursa olsun her çağrılışında gerçekten sabit bir maliyet tükettiğinde — örneğin bir donanım eylemi (gönderilmiş SMS), sınırda atomik olan bir mutasyon (DNS güncellemesi) veya backend'i 'denedik ve başarısız olduk' ile 'yaptık ve fark etmedin'i ayırt edemeyen bir servis. Okuma türü veri API'leri ve arama API'leri için bu model oturmuyor.