Müşteri tarafında HATEOAS'ın amacı nedir?

Halen anladığım kadarıyla HATEOAS, temel olarak her şey, daha sonra yapılacaklar hakkında bilgi içeren her bir yanıt bağlantısını bir araya getirmekle ilgilidir. Basit bir örnek internette kolayca bulunabilir: bir hesap kaynağı ile birlikte bir bankacılık sistemi. Örnek, bir hesap kaynağına bir GET isteğinin ardından bu cevabı gösterir.

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">100.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

Verilerle birlikte, daha sonra neler yapılabileceğini söyleyen bağlantılar vardır. Bakiye negatif ise,

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">-25.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
</account>

Böylece sadece para yatırabiliriz. Her şey yolunda, Fiddler kullanıyorsanız veya tarayıcıdan istekte bulunursak neler yapılabileceğini kolayca görebiliriz. Bu tür bilgiler API'nin yeteneklerini keşfetmemiz için yararlıdır ve sunucu istemciden ayrılır.

Ne var ki, bir müşteri oluşturduğumuzda, Javascriptli bir SPA veya bir Android uygulaması veya başka birçok şey gibi, HATEOAS'ın ne kadar alakalı olduğunu göremiyorum. Demek istediğim şudur: SPA'yı javascript'te kodlarken, kodu yazmak için API'de neler yapılabileceğini bilmeliyim.

Bu yüzden kaynakları, desteklenen yöntemleri, ne almayı umduklarını ve sunucuya ajax çağrıları yazmak için ve hatta kullanıcı arayüzünü oluşturmak için ne geri verdiklerini bilmem gerekiyor. Kullanıcı Arayüzünü kurduğumda, hesap isteğinde bulunduktan sonra, örneğin bir hesaba para yatırabileceğimi veya kullanıcı arayüzünde bu seçeneği sağlayamayacağımı bilmeliyim. Ayrıca, ajax çağrısını oluşturmak için para yatırmak için URI’yi bilmem gerekecek.

Demek istediğim, API'ye talepte bulunduğumuzda, bağlantılar bizim API'yi daha iyi keşfetmemize ve kullanmamıza izin veriyor, ancak bir müşteri oluşturduğumuzda, oluşturduğumuz uygulama sadece linklere bakmayacak ve sonra kendi kendine oluşturulacak Doğru UI ve doğru ajax çağrıları yapmak.

Peki HATEOAS müşterileri için nasıl önemlidir? Neden zaten HATEOAS ile uğraşıyoruz?

Yaptığımız uygulama basitçe bağlantılara bakmayacak ve sonra kendi başına doğru kullanıcı arayüzünü oluşturacak ve doğru ajax çağrılarını yapacak

Aslında, bu tam olarak HATEOAS neyi olacaktır UI verir. Değil Ne mümkün, ama ne zaman bu mümkün. Soru gibi, HAL gibi resmi bir HATEOAS , neyin mümkün olduğunu gösteren bağlantılar verir. Ancak bu bağlantılar ortaya çıktığında uygulamanın durumuna bağlıdır. Dolayısıyla, bağlantılar zamanla kaynağında değişebilir (daha önce gerçekleştirilmiş olan eylemlere dayanarak).

Bu, tüm olası durumları içeren bir UI oluşturmamızı sağlar , ancak bu durumların ne zaman aktif hale geldiği ile ilgilenmeyin . Örneğin, rel="deposit"kutunun varlığı make depositformu oluşturmanın uygun olduğu durumlarda kullanıcı arayüzüne doğrudan haber verebilir . Bu da kullanıcının bir değer girmesine ve bağlantıyı kullanarak göndermesine izin verir.

Halen anladığım kadarıyla HATEOAS, temel olarak her şey, daha sonra yapılacaklar hakkında bilgi içeren her bir bağlantı bağlantısını birlikte gönderme

HATEOAS sadece bağlantılardan çok daha fazlasıdır. Uygulama durumunun motoru olarak "hiper medya" dır.

Açıklamanızda eksik olan içerik türü ve istemci ile sunucu arasında geçen hiper medyanın biçimsel tanımıdır.

HTML, bir hiper medya örneği ve HATEOS'un neden çalıştığına bir örnektir. HTML sayfasının kendisi, müşterinin (yani kullanıcının) site içinde hareket etmesini sağlayan motordur. HTML'yi kullanıcıya tamamen gezilebilir bir web sitesi sunma yeteneğine sahip bir tarayıcı. Basitçe diğer sayfalara linkler iletmekle kalmaz, onları linklere içerik veren anlamlı bir şekilde ve tarayıcının gezinilebilir bir site inşa etmesine izin veren bir şekilde iletir.

Ve en önemlisi, tarayıcı bunu SIFIR web sitesinin kendisinin önceden anlaşılmasıyla yapabilir. Tarayıcı sadece HTTP ve HTML'yi bilir. Bu basit anlayışa dayanarak, gezinmek için kullanıcıya New York Times sunabilir.

Bu "kullanıcı" başka bir bilgisayar programı olsa bile geçerlidir. Hiper medyanın kendisi navigasyon içeriğini tanımlamalıdır.

Dinamik olarak oluşturulmuş bir arayüz oluşturmak zorunda değilsiniz. Güzel olsa da gerekli değil. Dinamik bir arayüz oluşturamazsanız, sadece bağlantıları kullanın ve bitirdiniz. Dezavantajı, arka uçla tekrar bağlantıda olmanızın zor olması ve bir şey değiştiğinde çarpışmanızdır.

Dinamik düzeni kullanmak oldukça basit olabilir:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

    case 'withdraw':
      loadWithdrawForm(link.href);
      showWithdrawButton();
      break;
  }

});

Sizi müşteri kodunuza kaydeder:

if (balance <= 0 && negativeBalanceAllowed === false) {
  showWithdrawButton();
}

Müvekkilinizi değiştirmeden izin verilen bir olumsuz pozisyonu (örneğin, borç para alarak) uygulayabilirsiniz.