Aynı Verinin Birkaç Doğru Yazılı Biçimi Vardır ve Bir İmza Yalnızca Birini Kapsar
Kendi veri katmanımız bu sayfanın konusu olan biçimi hiç üretmiyor ve gösterdiği sorun yine de bizi ilgilendiriyor.
Tek anlam, birçok yazım
Yapılandırılmış veri, anlamı değişmeden birden çok biçimde yazılabilir. Birbirinden bağımsız iki alanı yer değiştirin. Kısaltılmış bir adı tam hâline açın. Boşlukları değiştirin. Bir sayıyı 1 yerine 1.0 yazın.
Bunların her biri aynı bilgidir ve farklı bir bayt dizisidir.
Bir insan için bu dikkat çekmez. Bir imza için sorunun tamamıdır, çünkü imza anlamın değil baytların üzerindedir. Bir yazımı imzalayın, okuyucuya başkasını verin ve kimsenin değiştirmediği veride doğrulama başarısız olsun.
Bu neden varsayımsal değil gerçek bir çökme
Yeniden biçimlendiren herhangi bir şeyden geçen imzalı bir belge bozuk varır. Yeniden yayan bir ayrıştırıcı, saklayıp yeniden üreten bir veritabanı, güzelleştiren bir vekil sunucu, alanları imzalayandan farklı sıralayan bir kütüphane.
Belge sağlam. İmza sağlam. Kontrol başarısız. Ve hata mesajı imzanın geçersiz olduğunu söyler, ki bu herkesi var olmayan bir anahtar sorunu aramaya gönderir.
Düzeltme kanonikleştirmedir: herhangi bir yazımı tek bir tanımlı biçime çeviren üzerinde anlaşılmış bir yordam, böylece imzalayan ve doğrulayan, arada ne olduğundan bağımsız olarak aynı baytları özetler.
Kanonikleştirme her JSON-LD kimlik bilgisi sisteminin gösterişsiz kısmıdır, birlikte çalışabilirlik hatalarının kayda değer bir kısmının yaşadığı yerdir ve satıcı materyalinde neredeyse hiç anılmaz.
Onu atlatan diğer yaklaşım
Belgeyi imzalı bir zarfa sarın ve iletildiği hâliyle tam baytları imzalayın. Kanonik biçime gerek yok, çünkü hiçbir şeyin bir şeyi yeniden biçimlendirmesine izin verilmez: yük opaktır ve tek parça hâlinde hareket eder.
Bu daha basittir ve bir şeyden vazgeçer. Belge artık bağımsız olarak okunabilir ya da yeniden sıralanabilir değildir ve bağlantılı veri modelinin var olma sebebi olan birleştirme davranışı onunla birlikte gider.
Hiçbir seçim yanlış değildir. Bir hata sınıfını bir yetenek sınıfıyla takas ederler ve bir satıcının hangi takası yaptığını bilmek, sonradan neyin ters gideceğini size söyler.
Bağlantılı veri kimlik bilgileri olan bir satıcıya sorulacaklar
"Hangi kanonikleştirme algoritması ve hangi sürümü?" Adını söyleyemeyen bir satıcı hataya henüz çarpmamıştır. Çarpacaktır.
"Bir vekil sunucu kimlik bilgimi yolda yeniden biçimlendirirse ne olur?" Cevap, kuranları okuyanlardan ayırır.
"Sizin iki bağımsız uygulamanız birbirinin imzalarını hiç doğruladı mı?" Bu kusur sınıfını bulan tek test. Bizde benzeri test özel bir test değil uçtan uca yoldur.
"İmzanız belgenin üzerinde mi, bir zarfın üzerinde mi?" Kanonikleştirmenin sizin sorununuz olup olmadığını belirler.
Bu karar için ne anlama geliyor
Yeniden biçimlendirmeden sağ çıkan imzalı bağlantılı veri belgelerine ihtiyacınız varsa, onları üretmiyoruz ve yığınımızdaki biçimi konuşan bileşen, etrafındaki imzalama sorununu ele aldığımız iddiası değildir.
Kaygınız bir satıcının hangi çökme biçimlerini gerçekten düşündüğüyse, cevabımız bu sayfadır: biçim bizim değil, çökme sınıfı bizim, sistemimizde bambaşka bir yerde ortaya çıkıyor ve yokluğun bir bağışıklık gibi okunmasındansa size nerede olduğunu göstermeyi tercih ederiz.
Okumaya devam edin
- Ürünümüzdeki Uygunluğun Bir Kısmını Başkası Yazdı ve Hangi Kısımlar Olduğunu Bilmelisiniz
- İzinler Ancak Bir Şey Reddediyorsa Gerçektir ve Reddeden Şeyi Biz Yazmadık
- Kendi Depolama Katmanımız, Yanında Durduğumuz Veri Modelini Kullanmıyor ve Bu Gerçek Bir Uygunluk Açığıdır
- Hiç Tanışmamış İki Tarafın Konuşacak Bir Yola İhtiyacı Var ve O Yol E-posta Değil