İlk Kez SaaS Kurucuları İçin Kamu API Tasarımı: Temel İlkeler

Asıl sorun: sürdürülebilir bir API yayınlamak

Kamuya açık bir API, sadece uygulamanızın açtığı bir uç nokta değildir. Bu, ekip dışındaki insanlara verilen bir sözdür: sözleşme, ürün değişse bile çalışmaya devam edecek.

Zor olan kısım v1’i yazmak değil. Hataları düzeltirken, özellik eklerken ve müşterilerin gerçekte neye ihtiyaç duyduğunu öğrenirken onu kararlı tutmaktır.

Erken alınan kararlar daha sonra destek biletleri olarak geri döner. Yanıtlar şekil değiştirip önceden haber verilmezse, isimlendirme tutarsızsa veya istemciler isteğin başarılı olup olmadığını anlayamazsa sürtüşme oluşur. Bu sürtüşme güvensizliğe dönüşür ve geliştiriciler sizin üzerine inşa etmeyi bırakır.

Hız da önemlidir. Çoğu ilk kez SaaS kurucusu önce işe yarar bir şeyi hızlıca yayınlayıp sonra iyileştirmek ister. Ödün basittir: kurallar olmadan ne kadar hızlı yayınlarsanız, gerçek kullanıcılar geldiğinde o kararları geri almak için o kadar çok zaman harcarsınız.

v1 için yeterince iyi genellikle gerçek kullanıcı eylemlerine karşılık gelen küçük bir uç nokta seti, tutarlı isimlendirme ve yanıt biçimleri, net bir değişiklik stratejisi (sadece v1 bile olabilir), öngörülebilir sayfalandırma ve makul oran limitleri ile tam olarak ne gönderileceğini ve ne alınacağını gösteren doküman demektir.

Somut bir örnek: bir müşteri geceleyin fatura oluşturan bir entegrasyon kurduğunu düşünün. Sonradan bir alanın adını değiştirirseniz, tarih formatını değiştirirseniz veya kısmi sonuçlar döndürmeye başlarsanız onların iş akışı sabah 2’de çöker. Hatalar için sizi değil kendi kodlarını suçlarlar.

Koder.ai gibi sohbet tabanlı bir araçla geliştirirken birçok uç nokta üretmek cazip olabilir. Bu sorun değil, ama herkese açık yüzeyi küçük tutun. Öğrenirken dahili uç noktaları özel tutup hangilerinin uzun vadeli sözleşmenin parçası olması gerektiğini belirleyebilirsiniz.

Küçük, net bir API yüzeyiyle başlayın

İyi bir kamu API tasarımı, müşterilerin ürününüz hakkında konuştukları şekilde eşleşen küçük bir isim (kaynak) seti seçmekle başlar. İç veritabanınız değişse bile kaynak isimlerini sabit tutun. Özellik eklerken, temel kaynakların adını değiştirmek yerine alan eklemeyi veya yeni uç nokta açmayı tercih edin.

Birçok SaaS ürünü için pratik bir başlangıç seti: users, organizations, projects ve events. Bir kaynağı bir cümlede açıklayamıyorsanız, muhtemelen onu halka açmaya hazır değildir.

HTTP kullanımını sıkıcı ve öngörülebilir tutun:

• GET veriyi okur (yan etki yok)
• POST bir şey oluşturur (veya bir eylemi başlatır)
• PATCH bazı alanları günceller
• DELETE bir şeyi kaldırır veya devre dışı bırakır

Auth ilk günden süslü olmak zorunda değil. API’niz ağırlıklı olarak sunucu–sunucu ise (müşteriler backendlerinden çağırıyorsa), API anahtarları genellikle yeterlidir. Müşteriler bireysel son kullanıcı gibi davranacaksa veya üçüncü taraf entegrasyonlarında kullanıcılar izin verecekse OAuth genellikle daha uygun olur. Kararı sade dille yazın: çağıran kim ve hangi veriye dokunma hakkı var?

Beklentileri erken belirleyin. Neyin desteklendiği ile neyin iyi niyetli olarak ele alındığını açıkça ayırın. Örneğin: listeleme uç noktaları stabil ve geriye dönük uyumludur, ancak arama filtreleri genişleyebilir ve kapsamlı olmak zorunda değildir. Bu, destek biletlerini azaltır ve iyileştirme özgürlüğü verir.

Koder.ai gibi bir platform üzerinde inşa ediyorsanız, API’yi bir ürün sözleşmesi gibi ele alın: önce sözleşmeyi küçük tutun, sonra gerçek kullanım temelinde büyütün, tahminlerle değil.

Sürümleme — kendinizi köşeye sıkıştırmadan

Sürümleme büyük ölçüde beklentilerle ilgilidir. İstemciler merak eder: entegrasyonum gelecek hafta bozulur mu? Siz de iyileştirmek için alan istiyorsunuz.

URL sürümlendirme vs header sürümlendirme

Header tabanlı sürümlendirme temiz görünebilir, ama loglarda, cache’lerde ve destek ekran görüntülerinde kolayca kaybolabilir. URL sürümlendirme genellikle en basit seçenektir: /v1/.... Müşteri başarısız bir istek gönderdiğinde sürümü hemen görebilirsiniz. Ayrıca v1 ve v2’yi yan yana çalıştırmak kolaydır.

Gerçekte kırıcı değişiklik nedir?

Bir değişiklik, düzgün davranan bir istemci kodunu değiştirmeden çalışmayı durduracaksa kırıcıdır. Yaygın örnekler:

• Bir alanın yeniden adlandırılması (örneğin customer_id → customerId)
• Bir alan tipinin değiştirilmesi (string → number) veya anlamının değişmesi
• Bir uç noktanın veya istemcilerin güvenebileceği bir yanıt alanının kaldırılması
• Doğrulama kurallarının sıkılaştırılması (önceden isteğe bağlı olan şimdi zorunlu olursa)
• Yetkilendirme gereksinimlerinin veya varsayılan izinlerin değiştirilmesi

Güvenli bir değişiklik, eski istemcilerin görmezden gelebileceği bir değişikliktir. Yeni isteğe bağlı bir alan eklemek genellikle güvenlidir. Örneğin, GET /v1/subscriptions yanıtına plan_name eklemek, sadece status okuyan istemcileri bozmaz.

Pratik bir kural: aynı ana sürüm içinde alanları kaldırmayın veya amaçlarını değiştirmeyin. Yeni alanlar ekleyin, eski olanları tutun ve tüm sürümü kullanıdan kaldırmaya hazır olduğunuzda emekli edin.

Uygulanabilir bir deprecation politikası

Basit tutun: emeklileştirmeleri erken duyurun, yanıtlarda net bir uyarı döndürün ve bir bitiş tarihi belirleyin. İlk API için 90 günlük pencere sıklıkla gerçekçidir. Bu süre boyunca v1 çalışır durumda kalsın, kısa bir geçiş notu yayınlayın ve desteğin tek cümleyle yanıt verebildiğinden emin olun: v1 bu tarihe kadar çalışır; v2’de ne değişti.

Koder.ai gibi bir platformda inşa ediyorsanız, API sürümlerini snapshot gibi düşünün: iyileştirmeleri yeni bir sürümde yayınlayın, eskisini stabil tutun ve müşterilere taşınmaları için zaman verdikten sonra kapatın.

Tahmin edilebilir sayfalandırma desenleri

Sayfalandırma, güvenin kazanıldığı veya kaybedildiği yerdir. Sonuçlar istekler arasında sıçrıyorsa, insanlar API’nıza güvenmeyi bırakır.

Veri seti küçük, sorgu basit ve kullanıcıların sıkça 3. sayfaya geçmesi bekleniyorsa page/limit kullanın. Listeler büyüyorsa, yeni öğeler sık geliyorsa veya kullanıcı çok filtre/sıralama yapıyorsa cursor tabanlı sayfalandırma kullanın. Cursor tabanlı sayfalandırma, yeni kayıtlar eklendiğinde bile diziyi kararlı tutar.

Bir kaç kural sayfalandırmayı güvenilir kılar:

• Her zaman varsayılan bir sıralama tanımlayın (örneğin: created_at desc).
• Sıralamayı belirleyici kılmak için bir tie-breaker ekleyin (örneğin: id).
• Sayfalandırmayı sözleşmenin bir parçası olarak kabul edin: sıralamayı daha sonra değiştirmek kırıcı bir değişikliktir.
• Devam etmek için gereken minimumu döndürün: öğeler artı bir sonraki cursor (veya sonraki sayfa).

Toplam sayılar zor olabilir. total_count, filtrelerle büyük tablolarda pahalı olabilir. Ucuzca sağlayabiliyorsanız ekleyin. Sağlayamıyorsanız ya atlayın ya da bir sorgu bayrağı ile isteğe bağlı yapın.

Basit istek/yanıt şekilleri şu şekilde.

// Page/limit
GET /v1/invoices?page=2\u0026limit=25\u0026sort=created_at_desc

{
  "items": [{"id":"inv_1"},{"id":"inv_2"}],
  "page": 2,
  "limit": 25,
  "total_count": 142
}

// Cursor-based
GET /v1/invoices?limit=25\u0026cursor=eyJjcmVhdGVkX2F0IjoiMjAyNi0wMS0wOVQxMDozMDowMFoiLCJpZCI6Imludl8xMDAifQ==

{
  "items": [{"id":"inv_101"},{"id":"inv_102"}],
  "next_cursor": "eyJjcmVhdGVkX2F0IjoiMjAyNi0wMS0wOVQxMDoyNTowMFoiLCJpZCI6Imludl8xMjUifQ=="
}

Oran limitleri ve nazik yeniden denemeler

Oran limitleri sert olmakla ilgili değil, çevrimiçi kalmakla ilgilidir. Trafik dalgalanmalarından, sık yapılan pahalı sorgulardan ve beklenmeyen altyapı faturalarından korur. Bir limit aynı zamanda bir sözleşmedir: istemciler normal kullanımın ne olduğunu bilir.

Basit başlayın ve sonra ayarlayın. Tipik kullanım için alan tanıyan ve kısa patlamalara izin veren bir şey seçin, sonra gerçek trafiği izleyin. Veri yoksa güvenli bir varsayılan, API anahtarı başına dakika başına 60 istek ve küçük bir burst izni vermektir. Bir uç nokta çok daha ağırsa (örneğin search veya exports), onu daha katı bir limite veya ayrı bir maliyet kuralına tabi tutun; her isteği cezalandırmayın.

Limit uyguladığınızda istemcilerin doğru şeyi yapmasını kolaylaştırın. 429 Too Many Requests döndürün ve birkaç standart başlık ekleyin:

• X-RateLimit-Limit: pencere içindeki maksimum izin
• X-RateLimit-Remaining: kalan istek sayısı
• X-RateLimit-Reset: pencerenin ne zaman sıfırlanacağı (zaman damgası veya saniye)
• Retry-After: yeniden denemeden önce ne kadar beklenmesi gerektiği

İstemciler 429’u normal bir durum olarak görmelidir, savaşılacak bir hata olarak değil. Nazik bir yeniden deneme deseni iki tarafı da memnun eder:

• Retry-After varsa ona göre bekleyin
• Yoksa üstel geri çekilme kullanın (örneğin 1s, 2s, 4s)
• Biraz rastgelelik (jitter) ekleyin ki birçok istemci aynı anda yeniden denemesin
• Bekleme süresini sınırlayın (örneğin 30–60s)

Örnek: bir müşteri geceleyin yoğun bir senkron çalıştırıp API’nızı zorladığında, işleri tamamen başarısız olmak yerine 429’larla karşılaşıp 20 saniye duraklayabilir; sonra aynı cursor ile devam edip her şeyi tekrar indirmeden veya çift fatura oluşturmadan işi sürdürür.

Hatalar, durum kodları ve güvenli yazmalar

API hata mesajlarınız okunması zor ise destek biletleri hızla artar. Tek bir hata biçimi seçin ve 500’ler dahil her yerde ona sadık kalın. Basit bir standart: code, message, details ve kullanıcıların destek sohbetine yapıştırabileceği bir request_id.

Küçük, öngörülebilir bir format:

{
  "error": {
    "code": "validation_error",
    "message": "Some fields are invalid.",
    "details": {
      "fields": [
        {"name": "email", "issue": "must be a valid email"},
        {"name": "plan", "issue": "must be one of: free, pro, business"}
      ]
    },
    "request_id": "req_01HT..."
  }
}

HTTP durum kodlarını her zaman aynı şekilde kullanın: kötü giriş için 400, yetkilendirme eksik/hatlı ise 401, doğrulanmış ama erişimi yoksa 403, kaynak bulunamadıysa 404, çakışmalar için 409 (örneğin benzersiz değerin tekrar denenmesi veya yanlış durum), oran limitleri için 429 ve sunucu hataları için 500. Tutarlılık zekalı davranıştan iyidir.

Doğrulama hatalarını düzeltmeyi kolaylaştırın. Alan düzeyindeki ipuçları dokümanlarda kullandığınız parametre adını göstermeli, dahili veritabanı sütunu değil. Bir format gereksinimi varsa (tarih, para birimi, enum), kabul ettiğiniz biçimi söyleyin ve bir örnek gösterin.

Yeniden denemeler birçok API’nin kazara çift veri yaratmasına yol açar. Önemli POST eylemleri (ödeme, fatura oluşturma, e-posta gönderme) için idempotency anahtarlarını destekleyin:

• Seçili POST uç noktalarında Idempotency-Key header’ını kabul edin.
• Anahtarı sonucu ile birlikte kısa bir pencere için saklayın (örneğin 24 saat).
• Tekrarlanan anahtar üzerinde ilk istektekiyle aynı yanıtı döndürün.
• İlk istek hâlâ çalışıyorsa ikinci bir kaynak yaratmak yerine net bir tekrar deneyin yanıtı verin.

O bir header, ağ sorunları veya istemci zaman aşımı durumlarında birçok acı olayı önler.

Örnek senaryo: küçük bir SaaS faturalama API’si

Basit bir SaaS çalıştırdığınızı varsayın: üç ana obje var — projects, users ve invoices. Bir proje birçok kullanıcıya sahip ve her proje aylık faturalar alıyor. Müşteriler faturaları muhasebe araçlarına senkronize etmek ve kendi uygulamalarında temel faturalamayı göstermek istiyor.

Temiz bir v1 şöyle olabilir:

GET  /v1/projects/{project_id}
GET  /v1/projects/{project_id}/invoices
POST /v1/projects/{project_id}/invoices

Şimdi kırıcı bir değişiklik olsun. v1’de fatura tutarlarını sent olarak tamsayı saklıyorsunuz: amount_cents: 1299. Daha sonra çoklu para birimi ve ondalık ihtiyacı doğarsa amount: "12.99" ve currency: "USD" istiyorsunuz. Eski alanı üzerine yazarsanız tüm mevcut entegrasyonlar kırılır. Sürümleme paniği önler: v1’i stabil tutun, /v2/... ile yeni alanları gönderin ve istemciler taşınana dek her ikisine de servis verin.

Fatura listeleme için öngörülebilir bir sayfalandırma şekli kullanın. Örneğin:

GET /v1/projects/p_123/invoices?limit=50\u0026cursor=eyJpZCI6Imludl85OTkifQ==

200 OK
{
  "data": [ {"id":"inv_1001"}, {"id":"inv_1000"} ],
  "next_cursor": "eyJpZCI6Imludl8xMDAwIn0="
}

Bir gün bir müşteri faturaları döngü içinde içe aktarıp rate limite takılır. Rastgele başarısızlıklar yerine şu yanıtı alırlar:

• 429 Too Many Requests
• Retry-After: 20
• küçük bir hata gövdesi { "error": { "code": "rate_limited" } }

İstemci tarafında, 20 saniye duraklayıp aynı cursor ile yeniden başlayabilir; böylece her şeyi yeniden indirmek veya çift fatura oluşturmak zorunda kalmaz.

Adım adım: v1 API’niz için basit bir yayın planı

v1 lansmanı, bir uç nokta yığını değil küçük bir ürün sürümü gibi ele alındığında daha iyi gider. Amaç basit: insanlar üzerine inşa edebilsin ve siz sürpriz olmadan geliştirebilesiniz.

Küçük bir ekip için pratik 1 haftalık plan

API’nızın ne için olduğunu ve ne olmadığını açıklayan tek sayfalık bir şey yazarak başlayın. Yüzeyi bir dakikada sözlü olarak açıklayabileceğiniz kadar küçük tutun.

Bu sırayı izleyin ve her adım yeterince iyi olana kadar ilerlemeyin:

1. Çekirdek kaynaklarınızı ve destekleyeceğiniz ilk uç noktaları (5–10 düşünün) adlandıran tek sayfalık bir spesifikasyon taslağı hazırlayın. Taban URL desenini, auth yöntemini ve gerekli header’ları ekleyin.
2. Her uç nokta için bir gerçekçi istek ve bir gerçekçi yanıt yazın. Gerçek gönderilecek alan isimlerini kullanın. Bu örnekler ilk dokümanlarınız ve ilk testleriniz olur.
3. Kısa bir kurallar bölümü ekleyin: hatalar nasıl görünür, sayfalandırma nasıl çalışır (varsa), oran limitleri neler ve hangi alanlar stabil hangileri değişebilir.
4. Sahte bir istemci ile dahili test yapın. Müşteriymiş gibi yeni bir repo’da bir entegrasyon kurun. İlk başarılı çağrının ne kadar sürdüğünü zamanlayın ve nerede şaşırdığınızı not edin.
5. v1 sözleşmenizi yayınlayın: hangi değişiklikler güvenlidir (ekleyici alanlar), hangi değişiklikler yeni sürüm gerektirir ve kırıcı değişiklikler için ne kadar önceden haber vereceksiniz.

Kod üreten bir iş akışı ile (örneğin Koder.ai kullanarak uç noktalar ve yanıtlar üretiyorsanız) yine de sahte-istemci testini yapın. Üretilen kod doğru görünürken kullanımı garip olabilir.

Getirisi: daha az destek e-postası, daha az acil düzeltme yayımlama ve gerçekten sürdürülebilir bir v1.

Aşırı mühendislik yapmadan küçük bir SDK göndermek

İlk SDK ikinci bir ürün değildir. Bunu HTTP API’nızın ince, dostça bir sarmalayıcısı olarak düşünün. Sık kullanılan çağrıları kolaylaştırmalı, ama API’nin nasıl çalıştığını gizlememeli. Eğer sarmalanmamış bir özellik gerekiyorsa, kullanıcılar ham isteklere kolayca dönebilmeliler.

Başlamak için bir dil seçin; müşterilerinizin gerçekte kullandığına göre karar verin. Birçok B2B SaaS için genellikle JavaScript/TypeScript veya Python başlamak için iyi seçeneklerdir. Bir tam bitmiş üç SDK yerine bir sağlam SDK yayınlamak daha iyidir.

Küçük bir SDK neler içermeli

İyi bir başlangıç seti:

• Tek yerde kimlik doğrulama yönetimi (API key veya OAuth token)
• Mantıklı zaman aşımı ve güvenli istekler (GET) için otomatik yeniden denemeler, geri çekilme ile
• Sayfalandırma yardımcıları: iterator veya next page fonksiyonu
• Temiz istek/yanıt modelleri (basit tipler bile olsa)
• Özel header’lar ve ham HTTP çağrıları için kaçış kapısı

Bunu el ile yazabilir veya bir OpenAPI spesifikasyonundan üretebilirsiniz. Üretim, spesifikasyon doğruysa ve tutarlı tipleme istiyorsanız harikadır ama genellikle çok fazla kod üretir. Erken aşamada elle yazılmış minimal bir istemci ve dokümanlar için bir OpenAPI dosyası genellikle yeterlidir. Kamu SDK arayüzü stabil kaldığı sürece daha sonra üretilmiş istemcilere geçiş yapabilirsiniz.

SDK’yı API’den ayrı sürümlendirin

API sürümünüz uyumluluk kurallarını takip etmeli. SDK sürümünüz paketleme kurallarını takip etmeli.

Yeni isteğe bağlı parametreler veya yeni uç noktalar eklerseniz, genellikle küçük bir SDK güncellemesi yeterlidir. SDK’nın kendi içinde kırıcı değişiklikler (yeniden adlandırılmış metotlar, değişen varsayılanlar) için major sürüm ayırın, API aynı kalsa bile. Bu ayrım yükseltmeleri sakin tutar ve destek biletlerini azaltır.

Destek baş ağrılarına yol açan yaygın hatalar

Çoğu API destek bileti hata değil, sürprizlerle ilgilidir. Kamu API tasarımı büyük ölçüde sıkıcı ve öngörülebilir olmaktır ki istemci kodu aylarca çalışmaya devam etsin.

Güveni kaybetmenin en hızlı yolu yanıtları kimseye haber vermeden değiştirmektir. Bir alanın adını değiştirirseniz, tipini değiştirirseniz veya eskiden değer döndürdüğünüz yerde null dönmeye başlarsanız, istemciler için teşhis edilmesi zor kırılmalar olur. Gerçekten davranışı değiştirmeniz gerekiyorsa sürümleme yapın veya yeni bir alan ekleyin ve eskiyi açık bir sunset planıyla bir süre tutun.

Sayfalandırma bir diğer tekrar eden suçludur. Bir uç nokta page/pageSize, bir diğeri offset/limit ve üçüncüsü cursor kullanırsa, hepsinin farklı varsayılanları varsa sorun çıkar. v1 için bir desen seçin ve her yerde ona sadık kalın. Sıralamayı da sabit tutun ki yeni kayıtlar eklendiğinde sonraki sayfa atlamasın veya tekrar etmesin.

Hatalar tutarsız olduğunda çok fazla gidip gelme olur. Yaygın bir hata modu, bir servisin { "error":"..." } döndürmesi ve diğerinin { "message":"..." } döndürmesi ve aynı sorun için farklı HTTP durum kodları kullanmasıdır. İstemciler, karmaşık, uç nokta-spesifik işleyiciler geliştirir.

Uzun e-posta zincirleri üreten beş hata:

• Alanlarda sessiz değişiklikler (isimler, tipler, anlam) sürüm artışı veya deprecate pencere olmadan
• Uç noktalara göre değişen veya zamanla varsayılanları değişen sayfalandırma kuralları
• Uç noktalar arasında farklı hata formatları, durum kodları veya doğrulama mesajları
• Eksik request_id; böylece her iki taraf da tam başarısız çağrıyı loglarda bulamaz
• Ani tetiklenen rate limitler, başlıksız, net yeniden deneme rehberi ve örnek backoff olmaması

Basit bir alışkanlık faydalıdır: her yanıtta bir request_id olsun ve her 429 ne zaman yeniden deneneceğini açıklasın.

Hızlı kontrol listesi ve sonraki adımlar

Her şeyi yayınlamadan önce tutarlılığa odaklanan son bir geçiş yapın. Çoğu destek bileti küçük ayrıntıların uç noktalar, dokümanlar ve örnekler arasında uyuşmamasından doğar.

En çok problemi yakalayan hızlı kontroller:

• İsimlendirme: tutarlı isimler, çoğul kaynaklar ve alan kasa (birini seçip sürdürün).
• Örnekler: her uç noktanın bir gerçekçi istek ve yanıt örneği olsun, sayfalandırma dahil.
• Hatalar: net bir hata biçimi, stabil hata kodları ve sık başarısızlıklar için yardımcı mesajlar.
• Limitler: oran limit davranışı dokümante edilmiş olsun ve yanıtlarda beklenen başlıklar yer alsın.
• Güvenlik: oluşturmalarda idempotency ve zaman aşımı durumlarının öngörülebilir ele alınması.

Lansmandan sonra insanların gerçekte nereye istek attığını izleyin, umut ettiğiniz değil. Erken aşamada küçük bir gösterge panosu ve haftalık gözden geçirme yeterlidir.

İlk izleyeceğiniz sinyaller:

• 429 sıçramaları (kim limitleniyor ve neden)
• Her uç nokta için p95 gecikme (yavaş uç noktalar genelde N+1 sorgularını saklar)
• En çok kullanılan uç noktalar ve parametreler (gerçek API yüzeyiniz)
• Durum kodlarına göre hata oranları (400 vs 401 vs 500)
• Zaman aşımı ve yeniden denemeler (istemciler döngüde olabilir)

Geri bildirimi toplarken her şeyi yeniden yazmayın. Dokümanlarda kısa bir hata rapor yolu ekleyin ve her raporu uç nokta, request id ve istemci sürümü ile etiketleyin. Bir şeyi düzelttiğinizde, değişiklikleri ekleyici yapmayı tercih edin: yeni alanlar, isteğe bağlı parametreler veya yeni uç noktalar; mevcut davranışı bozmayın.

Sonraki adımlar: kaynaklarınızı, sürümleme planınızı, sayfalandırma kurallarınızı ve hata formatınızı içeren tek sayfalık bir API spesifikasyonu yazın. Sonra dokümanlar ve kimlik doğrulama artı 2–3 çekirdek uç noktayı kapsayan küçük bir başlangıç SDK’sı üretin. Daha hızlı gitmek isterseniz, Koder.ai gibi sohbet tabanlı planlama araçlarıyla spesifikasyon, doküman ve starter SDK taslağını çıkartabilirsiniz (planlama modu, uç noktaları ve örnekleri kod üretmeden önce haritalamak için kullanışlıdır).