Uygulamayı denediğimde, REST ile ilgili birkaç kavram kafamda çatışıyor.
İş mantığını tutan bir REST ful ful API sistemine ve kullanıcı arayüzünü sağlayan bir web uygulamasına sahibim. REST ile ilgili çeşitli kaynaklardan (özellikle Uygulamadaki REST: Hypermedia ve Systems Architecture ) Varlıklarımın ham tanımlayıcılarını göstermemeliyim, köprüleri geri getirmem gerektiğini biliyorum rel="self".
Örnek düşünün. REST api bir kişiyi döndüren bir kaynağa sahiptir:
<Person>
<Links>
<Link rel="self" href="http://my.rest.api/api/person/1234"/>
</Links>
<Pets>
<Link rel="pet" href="http://my.rest.api/api/pet/678"/>
</Pets>
</Person>
Sorun web uygulaması ile ortaya çıkar. Tarayıcılara köprü içeren bir sayfa döndürdüğünü varsayalım:
<body class="person">
<p>
<a href="http://my.web.app/pet/???????" />
</p>
</body>
Özelliğe ne koymalıyım href? Bir kullanıcı hedef sayfayı açtığında varlık varlık URL'sini web uygulamasında nasıl tutabilirim?
Gereksinimler çelişkili görünüyor:
- Köprü
hrefweb uygulamasına yönlendirmelidir, çünkü bu UI'yi barındıran sistemdir hrefWeb uygulaması hedef sayfası açıldığında varlık ele almak gerekir, çünkü varlığın bazı kimliğine sahip olmalıdır- Web uygulaması REST URL'lerini ayrıştırmamalı / inşa etmemelidir, çünkü bu REST-ful değildir.
URI'ler tüketicilere şeffaf olmamalıdır. Sadece URI'yi veren kişi, nasıl yorumlanacağını ve bir kaynağa eşleneceğini bilir.
Bu nedenle, yalnızca 1234API yanıt URL’sini alamıyorum , çünkü RESTful bir müşteri olarak ona sanki bir şeymiş gibi davranmalıyım http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j. Diğer taraftan, web uygulamamı yönlendiren bir URL vermeliyim ve uygulamanın bir şekilde API'nin orijinal URL'sini geri yüklemesi ve API kaynaklarına erişmek için bu URL'yi kullanması için yeterli.
En basit yöntem muhtemelen kaynakların API URL'lerini dize tanımlayıcıları olarak kullanmaktır. Ancak web sayfası URL'leri gibi http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234çirkin.
Her şey bir masaüstü uygulaması veya tek sayfalık bir javascript uygulaması için oldukça kolay görünüyor. Sürekli yaşadıkları için, URL'leri uygulama ömrü boyunca hizmet nesneleriyle birlikte bellekte tutabilir ve gerektiğinde kullanabilirler.
Bir web uygulamasıyla birkaç yaklaşım hayal edebiliyorum, ancak hepsi garip görünüyor:
- Ana makineyi API URL'lerinde değiştirin ve yalnızca sonucu saklayın. Büyük dezavantajı, web uygulamasının, API'nin oluşturduğu URL'yi ele almasını gerektirmesidir, yani canavarca kuplaj anlamına gelir. Ayrıca, bir daha RESTful değil, çünkü web uygulamam URL’leri yorumlamaya başladı.
- REST API'sindeki ham kimlikleri bağlantılarla birlikte gösterin, Web Uygulaması URL'lerini oluşturmak için bunları kullanın ve ardından API'deki gerekli kaynakları bulmak için web uygulaması sunucusundaki kimlikleri kullanın. Bu daha iyidir, ancak web uygulaması sunucu performansını etkileyecektir, çünkü web uygulamasının bir tarayıcıdan gelen herhangi bir isteği yerine getirmek için bir formun kimlik doğrulama istekleri zincirini yayınlayan REST servis navigasyonundan geçmesi gerekecektir. Biraz iç içe geçmiş bir kaynak için bu pahalı olabilir.
selfApi tarafından döndürülen tüm URL'leri web uygulaması sunucusunda kalıcı (DB?) Eşlemede saklayın. Onlar için bazı kimlikler oluşturun, web uygulaması sayfa URL'lerini oluşturmak ve REST hizmeti kaynaklarının URL'lerini almak için kimlikleri kullanın. Yanihttp://my.rest.api/pet/678URL'yi yeni bir anahtarla bir yerde tutuyorum, diyorum3ve web sayfası URL'sini olarak oluşturuyorumhttp://my.web.app/pet/3. Bu, bir tür HTTP Önbelleği uygulaması gibi görünüyor. Nedenini bilmiyorum ama bana çok garip geliyor.
Yoksa hepsi RESTful API'lerin web uygulamaları için arka uç olarak kullanamayacağı anlamına mı geliyor?