İstemciler yine de kullanmak için yeterince gelişmiş olmadığında bir REST API'sinde 'bulunabilirlik' ihtiyacı nedir?

İzlediğim çeşitli görüşmeler ve REST'te taradığım eğiticiler 'keşfedilebilirlik' adı verilen bir şeyi vurgulamaktadır. Sınırlı anlayışımla, bu terim, bir müşterinin gidebileceği http://URLve otomatik olarak yapabileceği şeylerin bir listesini alabileceği anlamına geliyor .

Anlamakta güçlük çektiğim şey, 'yazılım istemcilerinin' insan olmadığıdır. Bunlar, sağlanan bağlantılarla tam olarak ne yapılacağını anlamak için sezgisel bilgiye sahip olmayan programlardır. Yalnızca insanlar bir web sitesine gidebilir ve sunulan metin ve bağlantıları anlayabilir ve siteye göre hareket edebilir.

Öyleyse, bu tür keşfedilebilir URL'lere erişen istemci kodu, müşterinin insan geliştiricisi sunulan kaynaklarla gerçekten denemedikçe, onunla hiçbir şey yapamadığında keşfedilebilirliğin anlamı nedir? Bu, yalnızca farklı bir yönden ve aslında geliştirici için daha fazla çalışmayı içeren bir Belgeler kılavuzundaki kullanılabilir işlevler kümesini tanımlamakla tamamen aynı şeydir. Neden ikinci REST kaynaklarının dışındaki bir belgede neler yapılabileceğini önceden tanımlayan bu ikinci yaklaşım daha düşük olarak değerlendiriliyor?

Keşfedilebilirlik ihtiyacı ilgili olmayabilir, ancak keşfedilebilirliğe izin veren bağlantılar daha fazla amaca hizmet eder. Bunlardan en önemlisi, bence, istemciye verilen yanıtlarda tam URI'ler sağlamak, hiçbir müşterinin bir URI "oluşturmak" zorunda kalmayacağı anlamına gelir. Bu, hiçbir müşterinin URI'lerin nasıl yapılandırıldığı hakkında bilgiye ihtiyaç duymayacağı anlamına gelir. Ve bu da sunucu geliştiricilerinin URI şemasını kendilerine uygun olduğunda değiştirmelerine izin verir, çünkü eski istemcileri hala URI'leri yapılandırmanın eski bir yoluna güvenmeyi düşünmeleri gerekmez.

"İstemciler" bundan yararlanabilecek kadar gelişmiş olmayabilir, ancak istemci kullanıcıları bunu yapabilir. Bir istemci, sonuçta bir web tarayıcısı kadar basit bir şey olabilir. Keşfedilebilirlik, insanların API'yi öğrenmesini ve kullanmasını sağlamakla ilgilidir .

Örneğin Jenkins (CI sunucusu) REST benzeri bir arayüze sahiptir. Herhangi bir sayfaya gidin, URL'yi "/ api" ile düzeltin ve yapabileceğiniz her şeyi açıklayan bir sayfa elde edin. API öğrenmeyi önemsiz kılar. Örneğin, http://ci.jruby.org sizi jrubins için jenkins sunucusuna, http://ci.jruby.org/api ise o sayfa için api'ye götürür.

Bir süre önce, anlaşılması çok zor belgelere sahip bir API ile çalışmaktan zevk aldım.

Sunucudan gerçek bir yanıt almayı başardığımda, belgeleri sunucu yanıtıyla karşılaştırmak ve bunu belgeleri deşifre etmek (ve evet, doğru terim deşifre etmek) için kullanmak mümkün oldu. Sorun, spesifikasyona göre tam olarak doğru olmayan bir istek sunucuya gönderildiyse, sadece bir hata alırdınız ve okunamayan belgelerle, doğru isteklerin nasıl gönderileceğini bulmak imkansızdı. API belgelerinin birbiriyle hem de muhtemelen API'nın kendisiyle aynı fikirde olmayan farklı sürümleri de vardı; bu yardımcı olmadı.

Sunucuya gönderebileceğim bir komut olsaydı, olası tüm komutların bir listesini ve tam olarak nasıl gönderileceğini, son derece yardımcı olurdu. Keşfedilebilirlik sadece istemciler için değil, yazılım geliştiricileri için de yararlıdır.

NOT: Bu konuda uzman değilim, ancak birkaç yıl önce insanların "REST" hakkındaki yorumlarının farklı nüanslarını uzlaştırmaya çalışmak için benzer bir süreçten geçtim ve bu, saati.

Anladığım kadarıyla, Roy Fielding'in Uygulama Devleti Motoru aka "HATEOAS" olan Hipermedya'dan geliyor ve bu da "anlamsal ağ" fikrini kolaylaştırıyor.

Yani ... temel olarak ve yine anladığım kadarıyla, RESTful uygulamanızı temel olarak kendi kendini açıklayan bir şekilde yaparsınız, böylece tüketicinin içeriğinizi / işlevselliğinizi tüketmek için resmi bir sözleşme hakkında önceden bilgi sahibi olması gerekmez. Bazı varsayılan kök uç noktalarından etkileşime girebilir ve daha sonra, tüketici etkileşime girerken uygulamanızın sağladığı bağlamsal olarak alakalı bağlantıları yürütebilirler. Tüketici, elbette, bir kişi veya sistemik bir ajan olabilir.

Bir tüketicinin önceden bildiği bir sözleşmeye göre önceden bilmesi ve çağırması gereken CRUD işlemleriyle eşleştirilen güzel URL'ler için "REST" kullanıyorsanız, Roy Fielding bunu gerçekten RESTful olarak görmez.

Bu, REST aromalı bir RPC hizmeti kurulumunun yararlı olamayacağını / daha ayrıntılı bir RPC modeline göre bir iyileştirmenin ve sınırlı / kontrollü kullanıma uygun olmadığını söyleyemez, ancak hardliners burunlarını aşağıya bakacak ve dejenere olduğunu düşünecektir. / gerçekten REST değil.