Web servisi nedir?

Web servisi, uygulamaların bir ağ üzerinden veri alışverişi yaptığı veya işlev çağırdığı bir arayüzdür. Web sitesi öncelikle insanların okuması ve kullanması için tasarlanır; web servisi ise yazılım istemcilerine yönelik bir sözleşme sunar. Bir ürün ikisini birden sağlayabilir. Birçok servis HTTP ve JSON kullanır; ama terim başka protokolleri ve veri biçimlerini de kapsar.

İstek ve yanıt nasıl işler?

İstemci, tanımlı bir uç noktaya bir yöntem, parametreler ve gerektiğinde kimlik bilgileri içeren bir istek gönderir. Servis isteği doğrular, işlemi yapar ve bir yanıt döndürür. HTTP API'lerinde durum kodları sonucun genel türünü gösterir: başarılı yanıt, geçersiz girdi gibi istemci kaynaklı bir sorun ya da sunucu tarafında bir hata. Yanıt gövdesi genellikle belgelenmiş bir biçimde daha fazla ayrıntı verir.

Net bir sözleşme yolları, yöntemleri, alanları, türleri, kimlik doğrulamayı, istek sınırlarını ve hata durumlarını tanımlar. Böyle bir sözleşme sayesinde istemciler servisten bağımsız geliştirilebilir. Sürümleme önemlidir: bir alanı veya alanın yorumlanma biçimini değiştirmek, uç nokta adresi aynı kalsa bile mevcut uygulamaları bozabilir. Söz verdiğiniz yerde geriye dönük uyumluluğu koruyun ve kullanımdan kaldırma sürelerini duyurun.

Yaygın arayüz tarzları

REST tek bir veri iletim biçimi değil, bir mimari tarzdır. RESTful olarak tanımlanan HTTP API'leri kaynakları genellikle URL'lerle temsil eder ve okumak için GET, değişiklik için POST veya PUT gibi yöntemler kullanır. GET kalıcı bir durum değişikliği oluşturmamalıdır; istemciler ve ara katmanlar onu tekrarlayabilir veya önbelleğe alabilir. SOAP ise birçok kurumsal sistemde yapılandırılmış XML mesajları ve resmî servis tanımları kullanır.

GraphQL'de istemciler bir şemaya dayanarak, çoğu zaman HTTP üzerinden, yalnızca istedikleri alanları seçer. Bu, gereksiz veri aktarımını azaltabilir; ama sorgu maliyeti, yetkilendirme ve önbellek konularında işleri karmaşıklaştırır. Webhook'lar alışılmış yoklama (polling) düzenini tersine çevirir: bir olay gerçekleştiğinde bir servis kayıtlı bir uç noktayı çağırır. Webhook'larda göndericinin kimliğini doğrulamak, yeniden denemeleri yönetmek ve aynı olayın iki kez işlenmesini önlemek gerekir. Bu yaklaşımların hiçbiri her durumda en iyisi değildir.

Güvenlik ve gizlilik

Aktarım sırasındaki verileri korumak için HTTPS kullanın ve sunucu sertifikasını doğrulayın. Çağıranların kimliğini uygun bir kimlik bilgisi düzeniyle doğrulayın ve her işlemi ve nesneyi ayrı ayrı yetkilendirin. Geçerli bir token yalnızca kapsamının izin verdiği işlemleri yetkilendirir; gelişigüzel bir girdiyi güvenli hâle getirmez. İstek boyutunu ve türleri doğrulayın, hata mesajlarında özel verileri açığa çıkarmaktan kaçının ve kötüye kullanıma karşı sınırlar koyun.

Gizli bilgiler herkese açık URL'lerde, istemci tarafı kaynak kodunda veya günlüklerde yer almamalıdır. Açığa çıkmış kimlik bilgilerini yenileyin, kapsamlarını kısıtlayın ve üretim ile test için ayrı kimlik bilgileri kullanın. Geri çağırma (callback) URL'si kabul eden API'lerde, iç ağlara istek gönderilmesini önlemek için hedefleri doğrulayın. Hangi kişisel verilerin döndürüldüğünü belgeleyin ve yalnızca gerekeni saklayın.

Güvenilirlik ve performans

Ağlar arızalanır; bu yüzden istemcilerin zaman aşımlarına, sınırlı sayıda yeniden denemeye ve kısmi hataları net biçimde ele almaya ihtiyacı vardır. Güvenli olduğunda bir okuma işlemini yeniden deneyin; bir ödemeyi veya başka bir değiştirme işlemini yeniden denemek, yinelenmeyi önlemek için idempotent bir tasarım gerektirir. Sayfalama büyük sonuç kümelerini sınırlar. Önbellek, sabit kalan herkese açık veriler için yükü azaltabilir; hızla değişen veya özel yanıtlar ise dikkatli bir önbellek politikası gerektirir.

İşletmeciler gecikmeyi, hata oranlarını ve erişilebilirliği gerçek istemci yolundan ölçmelidir. HTTP 200 döndüren bir sunucu yine de eksik veya kullanılamaz veri döndürebilir; bu yüzden beklenen iş sonuçlarını da izleyin. İstek sınırları servisi korur; ama bu sınırlar öngörülebilir biçimde bildirilmelidir. Servis kullanıcılarınız için önemliyse olaylar sırasında başvurabilecekleri bir durum sayfası veya destek kanalı sunun.

Servis seçerken veya geliştirirken

İşe kullanıcının yapmak istediği işten ve veri sözleşmesinden başlayın, ardından istemcilerin uygulayabileceği ve ekibin sürdürebileceği bir arayüz tarzı seçin. Normal yanıtları, hatalı girdileri, süresi dolmuş kimlik bilgilerini, izinleri, sayfalamayı ve zaman aşımlarını test edin. Örnekleri güncel tutun ve somut hataları gösterin. Üçüncü taraf bir servisi entegre ederken kullanım sınırlarını, veri politikasını ve değişiklik duyurularını okuyun; en kullanışlı uç nokta bile sonuçta arızalanabilecek bir bağımlılıktır.