XML'i sunucuda ayrıştırmalı mıyım veya bir proxy sağlamalı mıyım ve tarayıcının onu ayrıştırmasına izin vermeli miyim?

Bir üçüncü taraf API ile arayüz gerekir. Bu API ile son kullanıcının tarayıcısından bir GET isteği yaparım ve bir XML yanıtı alırım. Bu veriler, kullanıcının içinden arama yapabileceği, karar vermek için kullanabileceği tarayıcı tabanlı bir uygulamada kullanılmalıdır. Ana sorun, çoğu tarayıcının alanlar arası XML kullanımını kilitlemesidir, bu yüzden basitçe alamıyorum API'dan XML.

Bununla birlikte, genel veriler temel olarak iki sete ayrılmıştır.

1. İlk veri kümesi herkese açıktır ve yalnızca sık sık güncellenmesi gerekir, böylece sunucu tarafındaki tüm kullanıcılar için önbelleğe alınabilir ve trafiği önemli ölçüde hafifletebilir.
2. İkinci veri kümesi özel ve her kullanıcı için ayrıdır. Bu veriler API'da daha sık güncellenir. Bu, önbelleğin çok daha az etkili olmasına yol açar.

Ölçeklenebilirlik nedeniyle, sunucunun yükünü olabildiğince küçük tutmak istiyorum.

Önümde iki seçenek görüyorum:

1. XML isteklerini 3. taraf sunucuya yönlendirmek ve istemci ile 3. taraf API arasında doğrudan ileri geri yönlendirmek için kullanılabilecek bir proxy sağlayın.
2. Sunucudan XML'den JSON'a dönüşüm gerçekleştirmesini ve gereksiz bilgileri çıkarmasını sağlayın. Bu aslında sunucumuz için 3. taraf API'dan gelen isteklere dönüşen yeni bir API yapmak anlamına gelir

Verileri kullanıcıya sağlamanın en iyi yolu ne olabilir? (İki seçenekten biri olması gerekmez)

Proxy seçeneği uygulanması en kolay olandır. Yapacak özel bir gelişiminiz yok, yapılacak tek şey bir proxy kurmak. Aynı zamanda basittir: sürdürülecek ek kod yoktur ve API değişirse, sizin tarafınızdan yapılacak değişiklikleriniz olmaz.

Proxy tercih edilen bir seçim olacaktır:

• Çalışan yazılımı hızlı bir şekilde göndermeniz gerekiyorsa. Bu, örneğin, bir özellik göndermek üzereyken, ancak projenin uygulama aşamasında yalnızca etki alanları arası AJAX istekleri yapamayacağınız tespit edildiğinde iyi bir seçimdir.

• Ya da mevcut API iyi tasarlanmışsa : mimari iyi, çağrılar çok net, belgeler eksiksiz ve anlaşılması kolay.

• Veya geçerli API değişebilirse. Değişirse, JavaScript uygulamasını değiştirmeniz yeterlidir. Proxy yerine, sonuçları ayrıştırıyor ve kendi JSON'unuzu oluşturuyorsanız, API'daki değişikliklerin sunucu tarafı kodunuzdaki değişiklikleri gerektirme riski vardır.

Öte yandan, sonucun ayrıştırılmasının, istemci tarafında API'yı tamamen soyutlamayı mümkün kılma avantajı vardır. Bu, daha yavaş bir alternatiftir, çünkü yeni arayüzü tasarlamak (orijinal API iyi tasarlanmamışsa) ve çıkarma, dönüştürme ve yükleme özelliklerini uygulamak gerekir, ancak büyük bir proje için iyi bir uzun vadeli seçim olabilir. Bu tercih edilen bir seçimdir:

• Ek özelliklere ihtiyacınız varsa. Orijinal API'da bulunmayan, sıradan bir proxy sunucusu tarafından desteklenmeyen bir düzeyde önbellekleme veya şifreleme veya farklı bir kimlik doğrulama modeli gibi farklı özelliklerden yararlanabilirsiniz .

  Örneğin, AJAX isteklerinin sayısı sorun haline gelirse veya iki yönlü iletişim modeli mantıklıysa, Web Yuvaları uygulayabilirsiniz.

• Veya mevcut API iyi tasarlanmamışsa. Bir cephe modeli gibi, bu yaklaşım API'yi yeniden tasarlamanızı sağlar. Orijinal olan fakirse, bir cepheye sahip olmak, eski bir API'nın orijinal yazarları tarafından yapılan kötü tasarım seçimlerini çözmeyi mümkün kılar. API'nın genel mimarisi gibi büyük parçalarda olduğu kadar argüman adları veya hata mesajları gibi ayrıntılarda da hareket edebilirsiniz.

  Varolan bir API'yi değiştirmek bazen imkansız olsa da, bir cepheye sahip olmak, orijinal tasarımdaki dezavantajları ve hataları soyutlayan bir parça temiz kodla çalışmayı mümkün kılabilir.

• Veya geçerli API değişebilirse. Aslında, API zaman içinde değişirse, cephenizin genel arayüzünü etkilenmeden tutarsa, JavaScript yerine sunucu tarafı kodunu değiştirmeyi tercih edebilirsiniz. Sunucu tarafı programlama konusunda daha deneyimli olmanız veya sunucu tarafı yeniden düzenleme için daha fazla araç bildiğiniz için veya projenizde sunucu tarafı kod sürümüyle başa çıkmanın daha kolay olması nedeniyle daha kolay olabilir.

JSON, performans, önbellekleme, vb. Hakkında konuşmayı ihmal ettiğimi fark edebilirsiniz. Bunun bir nedeni var:

• JSON ve XML: Doğru teknolojiyi seçmek size kalmış . Bunu, JSON üzerinden XML'in aşırı ısınmasını, verileri serileştirmek için gereken süreyi ve ayrıştırma kolaylığını objektif olarak ölçerek yaparsınız.

• Performans: farklı uygulamaları kıyaslayın, en hızlı olanı seçin, daha sonra profil oluşturun ve profil oluşturucunun sonuçlarına göre optimize edin. İşlevsel olmayan gereksinimlerde belirtilen performansa ulaştığınızda durun.

  Ayrıca, neyi başarmaya çalıştığınızı anlayın. Birbirleriyle etkileşime giren birkaç bölüm vardır: orijinal API, sunucunuz ve API'nin bant genişliği, sunucunuzun performansı, sunucunuz ve son kullanıcılar arasındaki bant genişliği ve makinelerinin performansı. Bir talebe 30 ms içinde yanıt almanız istenirse, ancak orijinal API 40 ms harcar. İsteği işleme koyarsanız, ne yaparsanız yapın, gerekli performansı elde edemezsiniz.

• Önbellek: önbellekleme, web uygulamanızı daha hızlı hissettiren, bant genişliğini azaltan vb.

  1. HTTP üstbilgilerini doğru şekilde kurmanın genellikle zor olduğu düşünüldüğünde, istemci önbelleğini de kullandığınızdan emin olun (sunucu tarafı önbellekleme, siz ve müşteriler arasındaki bant genişliği kullanımını azaltmaz).

  2. Neyin önbelleğe alınacağını, ne kadar süre ve geçersiz kılınacağını doğru bir şekilde belirlediğinizden emin olun: ürünün açıklaması 10 saniye önce değişti, ancak bir e-ticaret web sitesinin müşterileri hala eski sürümü görüyorsa, sorun değil. Sahibi açıklamayı değiştirdiyse, gönderdiyse ve önbelleğe alma nedeniyle önceki varyantı görüyorsa, bu sorunludur.

  3. Yalnızca önbelleğe odaklanma. Örneğin, küçültme de önemlidir. İstek sayısının azaltılması da yararlı olabilir.

Görmediğiniz üçüncü bir seçenek daha vardır: Çapraz Kaynak Kaynağı Paylaşımı (CORS) .

CORS standardı, sunucuların izin verilen kaynak etki alanlarına kaynak sunmasına izin veren yeni HTTP üstbilgileri ekleyerek çalışır. Tarayıcılar bu başlıkları destekler ve belirledikleri kısıtlamalara uyar.

Örnek : Sitenizin http://my-cool-site.com olduğunu ve http://third-party-site.com alan adında AJAX üzerinden erişebileceğiniz bir üçüncü taraf API'nız olduğunu varsayalım.

Ve varsayalım ki benim-cool-site.com adresinden sunucunuz bir sayfanın third-party-site.com adresine istekte bulunduğunu varsayalım. Normalde, kullanıcılar tarayıcısı, Aynı Kökenli Güvenlik İlkesi uyarınca kendi alan adınız / alt alan adınız dışındaki herhangi bir siteye AJAX çağrılarını reddeder . Ancak tarayıcı ve üçüncü taraf sunucu CORS'i destekliyorsa, aşağıdakiler gerçekleşir:

• Tarayıcı, şu HTTP üstbilgisini third-party-site.com adresine gönderir

  Origin: http://my-cool-site.com

• Üçüncü taraf sunucu alan adınızdan istekleri kabul ederse, şu HTTP üstbilgisiyle yanıt verir:

  Access-Control-Allow-Origin: http://my-cool-site.com

• Tüm alanlara izin vermek için üçüncü taraf sunucu bu başlığı gönderebilir:

  Access-Control-Allow-Origin: *

• Sitenize izin verilmiyorsa, tarayıcı bir hata verir.

İstemcinin CORS'yi destekleyen oldukça modern tarayıcıları varsa ve üçüncü taraf sunucunuz da CORS'i destekliyorsa , kodunuzda küçük değişiklikler yaparak kesinlikle bunu yapabilirsiniz.

Bunu yapmanın başka bir yolunu da bulabileceğiniz CORS hakkında güzel bir açıklama buldum : JSONP . Ancak JSONP, kodunuzda önemli miktarda değişiklik yapılmasını gerektirir.

Bir CORS isteği yapmak için XMLHttpRequestFirefox 3.5+, Safari 4+ ve Chrome'da ve XDomainRequestIE8 + 'da nesne kullanmanız yeterlidir . XMLHttpRequestNesne kullanırken , tarayıcı bir etki alanları arası istekte bulunmaya çalıştığınızı görürse, sorunsuz bir şekilde CORS davranışını tetikler.

İşte bir çapraz tarayıcı CORS nesnesi oluşturmanıza yardımcı olan bir javascript işlevi.

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        // XHR has 'withCredentials' property only if it supports CORS
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){ // if IE use XDR
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}

"Çoğu tarayıcı etki alanları arası XML kullanımını kilitledi" dediğinden, üçüncü taraf sunucunuzun CORS'yi desteklemeyebileceğini düşünüyorum. O zaman alternatif yaklaşımlar bulmalısınız.

Ölçeklenebilirlik nedeniyle, sunucunun yükünü olabildiğince küçük tutmak istiyorum

Bence bu aşağı yukarı cevabı gösteriyor. Önceden işlenmiş verilerin istemciye sağlanıp sağlanmayacağı esas olarak aşağıdakilere bağlıdır:

1. trafik açısından fark
2. işlemenin performans etkisi
3. farklı bir veri biçiminin istemci üzerindeki etkisi

XML karşılaştırmalı olarak küçükse veya yalnızca birkaç istek varsa, istemciye iletmek ve unutmak mantıklı olabilir. Önceden işlenmiş veriler hala orijinal verilerin büyük bir parçası olduğunda veya istemci farklı bir veri biçiminden fazla kazanç sağlayamıyorsa da geçerlidir (örneğin JSON).

Ancak, istemci büyük bir XML veri kümesini işlemeyle uğraşıyorsa veya istemci orijinal XML verilerinin yalnızca küçük bir kısmına ihtiyaç duyuyorsa, sunucu tarafında bir miktar önişleme yapmak mantıklı olabilir.

Sonunda, bir sunucuyu ölçeklemek bir istemciyi / tarayıcıyı veya kullanılabilir bant genişliğini ölçeklendirmekten daha kolaydır. Bir cümleye koymak, darboğazın sistemde nerede olduğuna bağlıdır.

Seçimim önbelleklemek ve sıkıştırmak (gereksiz bilgileri atmak) ve sonuçları istemci tarayıcısına, seçenek # 2'ye gzip etmektir . Çünkü tarayıcılar genellikle üst düzey CPU'lar değildir ve sunucudan tarayıcıya ağ hatları sınırlı kapasitededir. Mobil müşterilerden bahsediyorum . Mobil istemcileri desteklemeyi planlamıyorsanız, daha basit olanı seçin, örn.Google:CORS proxy