Bir Platformu Başka Bir Şeye Bağlamak Ne Gerektirir

Farklı işler için kullanılan iki arayüz biçimi

Bir aracı kurumun programlama arayüzü genellikle iki biçimde gelir. Biri kendisine her sorulduğunda bir soruyu yanıtlar ve aralarda hiçbir şey söylemez: bir istek gider, bir yanıt döner ve bir sonraki isteğe kadar başka bir şey bilinmez. Diğeri bir bağlantıyı açık tutar ve güncellemeleri oldukları anda gönderir, böylece bilgi istenmeden gelir.

Aracı kurumlar çoğunlukla ikisini de sunar ve bunlar bir seçenek listesinin ima ettiği anlamda birbirinin alternatifi değildir. Farklı sorulara yanıt verirler. Belirli bir anda belirli bir şey hakkında kesin bir yanıt gerektiren her şey — bu emrin durumu, hesapta şu anda ne olduğu — bir sorudur ve sorular birinci biçime aittir. Şeyler değişirken bunu bilmesi gereken her şey ikincisine aittir.

Tekrar tekrar sormanın altına inemediği bir taban vardır

Bir fiyata abone olmak yerine onu tekrar tekrar istemek, istekler arasındaki aralıktan daha taze olmayan bir görüntü verir. Aralığı yarıya indirmek bayatlığı yarıya indirir ve istek sayısını ikiye katlar; aracı kurumun bu sayıyı kabul etmediği bir nokta da vardır. Yani böyle elde edilen bir görüntünün ne kadar güncel olabileceğinin bir tabanı vardır ve bu tabanın nerede durduğuna başkası karar verir.

Bu kulağa geldiğinden daha önemlidir, çünkü bayatlık yol alır. Böyle alınmış bir rakamdan yapılan her karar, her gösterim, her karşılaştırma o rakamın yaşını devralır ve bunu söyleyen bir etiket taşımaz. Sorup sonra hareket eden bir sistem, yaşını çoğunlukla hiçbir yere yazmadığı bir sayıya göre hareket ediyordur.

Tek bir sınır, genellikle birkaç sınırdır

İstek sınırı, bir hesabın bir dönem içinde gönderebileceği istek sayısına konan tavandır ve nadiren tek bir sayıdır. Farklı uç noktalar ayrı sayılır ve fiyat okuma hakkı çoğunlukla emir gönderme hakkı değildir. Cömert olana göre boyutlandırılmış bir sistem katı olandan ret alabilir ve bunu en uygunsuz anda alır, çünkü emir trafiği tam da fiyat trafiğinin yoğunlaştığı anda yoğunlaşma eğilimindedir.

Hangi sınırların geçerli olduğu ve nasıl sayıldıkları aracı kurum tarafından belgelenir; deneyerek keşfedilmez. Duvarı içine yürüyerek bulmak, onun nerede durduğunu öğrenmek için ret harcamaktır — gerçek bir hesapta ve yürüyüşün denk geldiği anda.

Bir reddi ele almanın pahalı yolu

Hemen yeniden denemek istek sınırını kötüleştirir, çünkü denemeler de sayılır; kısıtlanmaya daha çok zorlayarak yanıt veren bir sistem kendini daha da kısıtlar. Bastırmak yerine geri çekilmek buradaki doğru davranışın tamamıdır ve tam da diğer arıza türlerinin çoğu ısrarı ödüllendirdiği için sezgiye aykırıdır.

Daha ciddi sorun, bir reddin diğer arızalardan her zaman ayırt edilememesidir. İstemci tarafında süresi dolan bir istek yine de alınmış ve işlenmiş olabilir; yanıt yokluğunu emir yokluğu saymak, bir sistemin aynı emri iki kez göndermesinin yoludur. Bir arayüz üzerinden işlem yapan her şeyin, yeniden hareket etmeden önce hesabı geri okuyarak gerçekte ne olduğunu ortaya koyması gerekir. Bu, yeniden denemekten farklı bir işlemdir ve önce gelmesi gereken odur.

Açık ama sessiz bir akış

Akış, tekrar tekrar sormanın tabanını kaldırır ve karşılığında kendi işini getirir. Bağlantılar kopar ve yeniden kurulması gerekir. Kopukluk sırasında kaçırılan güncellemelerin bir yerden telafi edilmesi gerekir; bu da genellikle boşlukta hiçbir şey olmadığını varsaymak yerine güncel durumu diğer türden arayüze sormak demektir.

Zor arıza bunların hiçbiri değildir. Hâlâ açık olan ve teslim etmeyi bırakmış bir bağlantıdır ve tam olarak sessiz bir piyasa gibi görünür — çünkü sessiz bir piyasa da hiçbir şey teslim etmez. Gelenin içeriğini incelemek ikisini ayıramaz, zira her iki durumda da hiçbir şey gelmemiştir. Onları ayıran zamandır: son mesajın içeriği değil, yaşı. Bir akışı tüketen yazılımın kendi kendine bayatlayan ve bunu söyleyen bir şeye ihtiyacı vardır; yoksa ölü bir bağlantıyı, o durum sürdüğü sürece sakin koşullar olarak okur.

Bir adrese gönderilen uyarı tek yönlüdür

Web adresine uyarı, bir grafikte tanımlanmış bir koşul gerçekleştiğinde platformun okuyucunun verdiği bir adrese mesaj göndermesidir; ekranda göstermek yerine ya da göstermeye ek olarak. Bir yerdeki analiz ile başka bir yerdeki eylem arasındaki alışılmış köprüdür ve çekiciliği açıktır: grafikte ifade edilen bir koşul başka bir yazılımın girdisi hâline gelir.

Anlaşılmaya değen şey, bunun gönder ve unut olmasıdır. Gönderen genellikle mesajın kabul edilip edilmediğini öğrenir ve onunla ne yapıldığına dair hiçbir şey öğrenmez. Teslimler geç, sırasız ya da birden fazla kez gelebilir. Başarısız olan bir mesaj yeniden denenebilir de denenmeyebilir de ve bu politika okuyucunun değil gönderenin politikasıdır. Bunların hiçbiri mekanizmayı kötü yapmaz. Onu, güvenceleri göründüğünden zayıf olan bir mekanizma yapar ve güçlü olanları varsaymak, en baştan sessiz bir arızayı yerleştirmenin yoludur.

Adres bir kimlik bilgisi değildir

Alıcının, isteğin kendisi kanıtlamadıkça, isteği kimin gönderdiğini anlamasının bir yolu yoktur. Dolayısıyla adres, uyarı ile adresi öğrenen herkes arasında duran tek şeydir ve adresler en sıradan yollarla sızar: bir destek talebine yapıştırılır, paylaşılan bir belgeye kopyalanır, bir ekran görüntüsünde görünür bırakılır.

Bu yüzden gelene göre hareket eden bir alıcının iki yükümlülüğü vardır ve ikisi de yukarıdakilerin tamamından çıkar. Mesajın geldiği olgusuna güvenmek yerine mesajı doğrulaması gerekir ve aynı mesajı iki kez görmeye, işi iki kez yapmadan katlanması gerekir. İkisi de ilgi çekici iş değildir, kurulum hâlâ denenirken ikisini de ertelemek kolaydır ve ikisi birlikte bir köprü ile bir çukur arasındaki farktır.