Hizmet

API geliştirme

Mevcut sistemlerinizi birbirine bağlayan API'ler geliştiriyoruz — web uygulamaları, mobil uygulamalar, ERP, CRM, iş ortakları ve veri kaynakları. Belgelenmiş, sürümlenmiş ve sistem altyapınızın geri kalanı güvenle üzerine kurulabilecek şekilde tasarlanmış.

Proje talebiProjeleri inceleyin
Genel bakış

Nedir — ve neleri kapsar?

Bir API; web uygulamalarının, mobil uygulamaların, iş ortaklarının ve ERP veya CRM gibi bağlı sistemlerin birbiriyle iletişim kurduğu arayüzleri sağlar. Batunet API'leri uzun ömürlü sözleşmeler olarak tasarlar — sürümlenmiş, belgelenmiş ve kararlı; böylece diğer her şey güvenle üzerine kurulabilir.

Hizmet kapsamı

  • API tasarımı (REST, GraphQL)
  • Kırılma olmadan sürümleme
  • Kimlik doğrulama ve rate limiting
  • Dokümantasyon ve geliştirici deneyimi (developer experience)
  • Güvenilir webhook'lar ve olaylar (event)
Kullanım alanları

Hangi projeler için uygun?

Şirketlerin bize getirdiği tipik başlangıç durumları — ve bunlarla ilgili yayımlanmış çalışmalarımız.

  1. Üçüncü taraf sistemleri ve veri kaynaklarını bağlamak

    İş ortakları, ağlar veya hizmet sağlayıcılar verileri kendi formatlarında iletir — dosya aktarımıyla, REST veya SOAP üzerinden. Her kaynağı kendi yoluyla bağlıyor ve verilerini sisteminize ait bir modele aktarıyoruz.

    Projelerimizden örnek

  2. Kendi arayüzleriniz ve uygulamalarınız için tek bir API

    Web sitesi, yönetim paneli ve mobil uygulama, iş mantığını her seferinde yeniden kurmak yerine aynı mantığı kullanmalı. Ortak bir API kuralları tek bir yerde tutar ve arayüzü iş mantığından temiz biçimde ayırır.

    Projelerimizden örnek

  3. Harici servisleri değiştirilebilir tutmak

    Bağlı servisler arayüzlerini sormadan değiştirir. Önlerine konan kendi sınırınız sürüm değişikliklerini ve hataları karşılar; böylece bir geçiş veri varlığınıza kadar yansımaz.

    Projelerimizden örnek

  4. Verilerinizi iş ortaklarına kontrollü biçimde açmak

    Müşteriler veya iş ortakları verilerinize ve süreçlerinize erişmeli — kimlik doğrulama, rate limiting ve soru sormadan çalışabilecekleri bir dokümantasyonla. Arayüz böylece yıllarca geçerli kalan bir sözleşmeye dönüşür.

Değerlendirme

Ne zaman uygun — ne zaman değil?

Projeye uyan yolu öneririz — bu hazır bir ürün olsa bile.

Uygun

  • Birden fazla çağıran aynı iş mantığını paylaşıyor — frontend'ler, mobil uygulamalar veya iş ortakları. İkinci çağırandan itibaren arayüz bir uygulama ayrıntısı değil, bir sözleşmedir.
  • Mevcut iş mantığı, yabancı sistemleri iç yapıya bağlamadan kontrollü biçimde erişilebilir hâle getirilmeli.
  • Harici bir hizmetin değiştirilebilir kalması gerekiyor. Önüne konan kendi arayüzünüz, kalıcı olanı değiştirilecek olandan ayırır.
  • Arayüz, kullanıcılarının canlı sistemlerini bozmadan yıllar boyunca eklemeli olarak büyümeli.

Uygun değil

  • Birlikte geliştirilen ve birlikte yayına alınan iki kendi servisiniz. Orada sözleşmeyi değiştirmek ucuzdur — daha sıkı bir bağlılık savunulabilir.
  • Kendiniz koordine ettiğiniz, birlikte büyüyen tek bir kullanıcı. Sözleşme alanı, kararlı hata kodları ve deprecation sürecinden oluşan tam katılık ancak yabancı çağıranlarda değer.
  • Bir prototip veya kısa ömürlü bir arayüz. Orada dahilî yapıları doğrudan yansıtmak daha hızlı ve doğru seçimdir; ayrışma ancak API uzun yaşadığında değer.
Referanslar

Benzer çalışmalar.

Yayımlanmış projeler; her birinde bizim üstlendiğimiz kısım belirtilmiştir. Diğer referansları görüşmede paylaşırız.

Tipik riskler

Erken fark ettiğimiz riskler.

Bu tür sistemlerde tipik olarak neyin ters gittiği — ve bunu canlı ortamda görünür hâle gelmeden nasıl önlediğimiz.

  1. Sessiz breaking change

    Neden
    Yeniden adlandırılmış bir alan veya sonradan sıkılaştırılmış bir doğrulama bir düzeltme gibi görünür. Karşı taraftaki yabancı kod için ise bu bir kırılmadır — değişiklik ne kadar küçük görünürse görünsün.
    Erken uyarı işaretleri
    Eklemeli genişletmeler yerine mevcut yapıda değişiklikler; herkese açık sözleşmeye karşı otomatik test yok; hatayı kendi izleme sisteminizden önce çağıran taraf bildiriyor.
    Nasıl önlüyoruz
    Mümkün olan yerde eklemeli genişletmek. Herkese açık sözleşme yayına almadan önce otomatik olarak test edilir; yeni bir sürüm gerekirse eskisi dokunulmadan geçerli kalır.
    Ödünleşim
    Bedeli: Contract testleri ve mevcut yapıyı değiştirmekte temkinlilik. Farklı durum: Arayüz tamamen dahiliyse ve çağıranlarıyla birlikte yayına alınıyorsa sözleşmeyi değiştirmek ucuzdur.

  2. Sözleşmesi olmayan hatalar

    Neden
    Hatalar sözleşmenin bir parçasıdır, yanında duran bir uç durum değil. Değişen serbest metinler, çağıranları ifadeleri kontrol etmeye zorlar — ve mesajın kendisini sözleşmeye dönüştürür.
    Erken uyarı işaretleri
    Kararlı, sınıflandırılmış bir kod yok; istemci ve sunucu hataları ayırt edilemiyor, dolayısıyla kimse tekrar mı denemesi yoksa düzeltme mi yapması gerektiğini bilmiyor; mesajlarda dahilî ayrıntılar.
    Nasıl önlüyoruz
    Kararlı, makine tarafından değerlendirilebilir hata kodları, çağıranın hatası ile sağlayıcının hatası arasında net bir ayrım ve yanıtta dahilî iz bırakılmaması.
    Ödünleşim
    Bedeli: Başarılı yanıtlarla aynı özenle bakımı yapılması gereken ek bir sözleşme alanı. Farklı durum: Birlikte büyüyen tek bir kullanıcısı olan dahilî bir arayüzde hata modeli daha yalın kalabilir.

  3. Arayüzü uygulamayla karıştırmak

    Neden
    Bir arayüzün arkasındaki sağlayıcı değiştirilebilir; o arayüzden akıp kalıcı hâle gelen veriler ise değiştirilemez. Kendi bakış açısını bir sağlayıcının yapısına bağlayan, her değişikliği mevcut verilere kadar hisseder.
    Erken uyarı işaretleri
    Kendi veri modeli harici bir hizmetin yapısını izliyor; sağlayıcı değişikliği, mevcut verilerin dönüştürülmesi olarak değil, bir bağlantı meselesi olarak planlanıyor.
    Nasıl önlüyoruz
    Veriler sisteme ait bir biçimde tutulur; harici hizmet, ayakta kalan bir sınırın arkasında durur.
    Ödünleşim
    Bedeli: Doğrudan geçiş yerine bir çeviri katmanı ve kontrollü biçimde taşınmış mevcut veriler. Farklı durum: Mevcut veriler küçük ve kritik değilse ve yeniden temin edilmeleri ucuzsa.
Önceden netleştirilecekler

Uygulamadan önce net­leş­tir­di­ği­miz sorular.

Mimariyi araç seçiminden çok sizin yanıtlarınız şekillendirir.

  1. İletişim hangi biçimde — nesneler, eylemler mi, yoksa esnek sorgular mı?

    Neden önemli
    Stil sözleşmeyi şekillendirir ve sözleşmeyi değiştirmek zordur. Modaya göre karar vermek, bir uygunluk sorusunu zevk meselesi gibi ele almak demektir.
    Tipik sonuç
    Adlandırılmış nesneler REST'e, bilinen sistemler arasındaki eylemler RPC'ye, çok sayıda çağıranın çok farklı veri kesitlerine ihtiyaç duyması GraphQL'e götürür. Emin olunamadığında: on yıl sonra da anlaşılacak ve bilen ekip bulunabilecek en yaygın stil.

  2. Arayüz çağıranın iş alanını mı ifade ediyor — yoksa dahilî uygulamayı mı?

    Neden önemli
    Bir kullanıcının gözlemlediği her şey sözleşmeye dönüşür. Aynen yansıtılan dahilî yapılar, yabancı sistemleri serbestçe değiştirmek istediğiniz kararlara bağlar.
    Tipik sonuç
    Dış temsili dahilî modelden ayrı tasarlıyor ve sınırda çeviri yapıyoruz. Kısa ömürlü bir prototipte buna gerek kalmaz.

  3. Bir işlem durumu veya parayı değiştiriyor mu?

    Neden önemli
    Bir API ağ üzerinden erişilebilir olduğu anda aynı istek eninde sonunda iki kez gelir. Bu bir hata değil, dağıtık iletişimin bir özelliğidir.
    Tipik sonuç
    Bu durumda işlem mükerrer işlemleri önleyen (idempotent) tasarlanır: her mantıksal işlem için benzersiz bir anahtar, etkiyle aynı transaction içinde kontrol edilir ve kalıcı olarak kaydedilir. Okuma işlemleri ve doğası gereği mükerrer işlemleri önleyen (idempotent) işlemler buna ihtiyaç duymaz.

  4. Mevcut bir çağıran planlanan değişikliği fark edebilir mi?

    Neden önemli
    Cevap evetse değişiklik kırıcıdır — ne kadar küçük görünürse görünsün. Sonradan sıkılaştırılmış bir doğrulama da bir kırılmadır.
    Tipik sonuç
    Mümkün olan yerde değişikliği eklemeli olarak çözüyoruz. Mümkün değilse yeni bir sürüm oluşur, eskisi dokunulmadan geçerli kalır ve kapatma, belirli bir son tarih yerine önceden duyurulan bir deprecation sürecini izler.
Proje süreci

İlk görüşmeden çalışan sisteme.

Her proje aynı dört adımı izler. Ara sonuçları yalnızca sonda değil, süreç boyunca görür ve değerlendirirsiniz.

  1. 01

    İhtiyacı anlamak, gereksinimleri netleştirmek

    İlk görüşmede bağlanacak sistemleri ve arayüzü kimlerin kullanacağını doğrudan şirket yönetimiyle konuşursunuz. Veri akışlarını ve hata durumlarını çıkarır, arayüzün ne kadar sıkı kurallara ihtiyaç duyduğunu dürüstçe söyleriz.

  2. 02

    Çözümü ve mimariyi planlamak

    Sözleşmeyi tasarlarız: kaynaklar veya eylemler, hata kodları, kimlik doğrulama, sürümleme. Tasarım, kod yazılmadan önce belgelenir.

  3. 03

    Geliştirmek ve birlikte kontrol etmek

    Önce iki sistem arasında eksiksiz bir akış çalışır, ardından genişlik gelir. Otomatik testler, dağıtımdan önce açık sözleşmeyi kontrol eder.

  4. 04

    Yayına almak ve desteğe devam etmek

    Yayına alındıktan sonra isterseniz çağrıları ve hataları izler, mevcut kullanıcıları bozmadan API'yi eklemeli olarak genişletiriz.

İş birliğinin ayrıntıları →
Sonuç

Proje sonunda elinizde olanlar.

  • Kırılmadan gelişen arayüzler

  • İş ortakları ve diğer sistemler için kararlı bir temel

  • Başkalarının hemen çalışmaya başlayabileceği dokümantasyon

Kullanılan teknolojiler

LaravelSymfonyRESTGraphQLOpenAPI
Sorular

API geliştirme hakkında sorular

  • REST mi, GraphQL mi?

    Kararlı, önbelleğe alınabilir kaynaklar için REST; istemciler çok farklı veri kesitlerine ihtiyaç duyuyorsa GraphQL. Çoğu zaman doğru seçim REST'tir — sıkıcı ama doğru.

  • Breaking change'lerden nasıl kaçınıyorsunuz?

    Bilinçli sürümleme, eklemeli değişiklikler ve net sözleşmelerle. Bir API, kullanıcılarına verilmiş bir sözdür.

Okumaya devam edin

İlgili konular.

Bu sayfayla bağlantılı rehberler, kararlar, hizmetler ve projeler.

Ara­yüz­le­ri­niz hakkında konuşalım.

Bağlanacak sistemleri ya da ihtiyaç duyduğunuz API'yi kısaca belirtin — kendi uygulamalarınız, iş ortaklarınız veya veri kaynaklarınız için. İlk görüşmeyi doğrudan şirket yönetimiyle yaparsınız.