Чи слід проаналізувати XML на сервері або надати проксі-сервер і дозволити веб-переглядачу розбирати його?

11

Мені потрібно взаємодіяти з стороннім API. За допомогою цього API я роблю GET-запит у веб-переглядачі кінцевого користувача та отримую відповідь XML. Ці дані мають використовуватися в додатку на базі браузера, де користувач може здійснювати пошук через нього, використовувати його для прийняття рішень тощо. Основна проблема полягає в тому, що більшість браузерів заблокували використання XML між доменами, тому я не можу просто отримати XML від API.

Однак загальні дані в основному розбиті на два набори.

  1. Перший набір даних є загальнодоступним і його потрібно оновлювати лише так часто, щоб його можна кешувати для всіх користувачів на стороні сервера, значно зменшуючи трафік.
  2. Другий набір даних є приватним та індивідуальним для кожного користувача. Ці дані також частіше оновлюються в API. Це призводить до кешування набагато менш ефективним.

З міркувань масштабування я хотів би зберегти навантаження сервера якомога менше.

Я бачу два варіанти перед собою:

  1. Надайте проксі-сервер, який може бути використаний для маршрутизації запитів XML на сторонній сервер та безпосередньо назад та назад між клієнтським та стороннім API.
  2. Нехай сервер здійснює перетворення з XML в JSON і викреслює непотрібну інформацію. Це по суті означає створення нового API для нашого сервера, який перетворюється на запити від стороннього API

Що було б найкращим способом надання даних користувачеві? (Не обов’язково бути одним із двох варіантів)

javascript  api  xml  websites  json 
— аметистдрагон
джерело
Який зв’язок джерела XML з кодом, який інтерпретує його у браузері? Тому що, якщо ви написали власний (непідтримуваний) код клієнта для подачі з якихось даних третьої сторони, перше, що я думаю, це те, що одного дня ця третя сторона внесе незначні зміни в XML і назавжди порушить вашу програму.
— SJuan76
Третя сторона вже оновлювала свою версію API. Вони трохи зберегли стару версію, дозволяючи людям оновити свій код, щоб використовувати новий API. Однак структура даних у XML не змінилася жодного разу визначеного, за винятком версій API.
— аметистдрагон
1
Якщо API часто змінюється, напевно, варто витратити час, щоб оголосити власну схему і мати службу, яка виступає в якості посередництва, маніпулюючи даними на те, що очікує ваш клієнт. Я думаю, що питання зводиться до "Що простіше, оновлення клієнта чи оновлення сервера?"
— Гіпербола
Це не часто. Він змінювався один раз за 10 років.
— amethystdragon

Відповіді:

12

Варіант проксі є найпростішим у здійсненні. У вас немає спеціальних розробок, які потрібно зробити, єдине, що потрібно зробити, це налаштувати проксі. Це також просто: немає додаткового коду для підтримки, і якщо API зміниться, у вас немає змін, які потрібно внести на вашу сторону.

Проксі-сервер буде кращим вибором:

  • Якщо вам потрібно швидко відправити робоче програмне забезпечення. Це робить його хорошим вибором, наприклад, якщо ви збиралися відправити функцію, але виявили на етапі впровадження проекту, що ви не можете просто робити міждоменні запити AJAX.

  • Або якщо поточний API добре розроблений : архітектура хороша, дзвінки дуже чіткі, документація завершена і зрозуміла легко.

  • Або якщо поточний API може бути змінений. Якщо вона зміниться, вам потрібно просто змінити реалізацію JavaScript. Якщо замість проксі ви аналізуєте результати та генеруєте свій власний JSON, існує ризик, що для зміни API потрібно змінити код вашого сервера.

З іншого боку, аналіз результату має користь, що дозволяє повністю абстрагувати API на стороні клієнта. Це більш повільна альтернатива, оскільки вимагає розробити новий інтерфейс (якщо оригінальний API недостатньо розроблений) та реалізувати функції вилучення, перетворення та завантаження, але це може бути хорошим довгостроковим вибором для великого проекту. Це кращий вибір:

  • Якщо вам потрібні додаткові функції. Ви можете використовувати різні функції, які були недоступні в оригінальному API, наприклад кешування на рівні, який не підтримується звичайним проксі-сервером, або шифрування або іншу модель аутентифікації .

    Наприклад, якщо кількість запитів AJAX стає проблемою, або якщо двостороння модель зв'язку має сенс, можна застосувати веб-сокети.

  • Або якщо поточний API недостатньо розроблений. Як і візерунок фасаду, такий підхід дозволяє переробити API. Якщо оригінал поганий, наявність фасаду дозволяє вирішити поганий вибір дизайну, зроблений оригінальними авторами застарілого API. Ви можете також діяти на великих частинах, таких як загальна архітектура API, але також і на деталях, таких як назви аргументів або повідомлення про помилку.

    Хоча змінити існуючий API іноді неможливо, наявність фасаду може зробити можливим роботу з фрагментом чистого коду, який усуває недоліки та помилки в оригінальному дизайні.

  • Або якщо поточний API може бути змінений. Дійсно, ви можете віддати перевагу зміні коду на сервері замість JavaScript, якщо API змінюється з часом, зберігаючи при цьому публічний інтерфейс вашого фасаду. Це може бути простіше або тому, що ви маєте більше досвіду програмування на стороні сервера, або тому, що знаєте більше інструментів для рефакторингу на стороні сервера, або тому, що у вашому проекті легше боротися з версіями коду на сервері.

Ви можете помітити, що я пропустив розмову про JSON, продуктивність, кешування тощо. Для цього є причина:

  • JSON проти XML: це до вас , щоб вибрати правильну технологію. Ви робите це об'єктивно, вимірюючи перегрів XML через JSON, час, необхідний для серіалізації даних та простоту розбору.

  • Продуктивність: орієнтир різних реалізацій, виберіть найшвидший, а потім профіліруйте його та оптимізуйте його за результатами профілера. Зупиніться, коли досягнете продуктивності, зазначеної в нефункціональних вимогах.

    Також зрозумійте, чого ви намагаєтесь досягти. Є кілька частин, що взаємодіють між собою: оригінальний API, пропускна здатність між вашим сервером та API, продуктивність вашого сервера, пропускна здатність між вашим сервером та кінцевими користувачами та продуктивність їх машин. Якщо вас попросять отримати відповідь на запит протягом 30 мс., Але оригінальний API витрачає 40 мс. обробляючи запит, незалежно від того, що ви робите, ви не зможете отримати необхідну ефективність.

  • Кешування: кешування - це один із прийомів, щоб ваш веб-додаток відчував себе швидше, зменшував пропускну здатність тощо.

    1. Переконайтеся, що ви також використовуєте кешування клієнтів (кешування на стороні сервера не зменшить використання пропускної здатності між вами та клієнтами), враховуючи, що правильно налаштувати заголовки HTTP досить складно.

    2. Переконайтеся, що ви правильно визначили, що потрібно кешувати, на скільки часу та коли його визнати недійсним: якщо опис продукту змінився 10 секунд тому, але клієнти веб-сайту електронної комерції все ще бачать стару версію, це добре. Якщо власник змінив опис, подав його та все ще бачить попередній варіант через кешування, це проблематично.

    3. Не зосереджуйтесь лише на кешування. Наприклад, важливим є також мінімізація. Скорочення кількості запитів також може бути корисним.

— Арсеній Муренко
джерело
1
+1 Я трохи вагався, чи варто згадувати кешування чи ні, і, нарешті, вирішив проти цього. Ще варто піднести це, хороший момент.
— JensG
7

Є ще третій варіант, який ви, можливо, не бачили: Перехресний розподіл ресурсів (CORS) .

Стандарт CORS працює, додаючи нові заголовки HTTP, які дозволяють серверам обслуговувати ресурси до дозволених доменів походження. Браузери підтримують ці заголовки та дотримуються встановлених ними обмежень.

Приклад . Скажімо, ваш сайт http://my-cool-site.com і у вас є API сторонньої сторони в домені http://third-party-site.com , до якого ви можете отримати доступ через AJAX.

І припустимо, що сторінка, на яку ви сервер із my-cool-site.com, подала запит на third-party-site.com. Як правило, браузер користувачів відхиляє дзвінки AJAX на будь-який інший сайт, окрім вашого власного домену / субдомену на політики безпеки аналогічним джерелом . Але якщо браузер і сторонній сервер підтримує CORS, трапляються такі дії:

  • Веб-переглядач надішле наступний HTTP-заголовок на third-party-site.com

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

  • Якщо сторонній сервер приймає запити від вашого домену, він відповість таким заголовком HTTP:

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

  • Щоб дозволити всі домени, третій сервер може надіслати цей заголовок:

    Access-Control-Allow-Origin: *

  • Якщо ваш сайт заборонений, браузер видасть помилку.

Якщо у клієнта є досить сучасні браузери, які підтримують CORS , а ваш третій сервер також підтримує CORS , ви, безумовно, можете скористатися цим, змінивши ваш код.

Я знайшов приємне пояснення на CORS , на якому ви також знайдете інший спосіб зробити це: JSONP . Але JSONP вимагає неабиякої кількості змін у вашому коді.

Щоб зробити запит CORS, ви просто використовуєте XMLHttpRequest Firefox 3.5+, Safari 4+ та Chrome та XDomainRequestоб’єктуйте в IE8 +. Якщо ви використовуєте XMLHttpRequestоб'єкт, якщо браузер бачить, що ви намагаєтеся зробити запит між доменами, він безперечно запускає поведінку CORS.

Ось функція javascript, яка допоможе вам створити крос-браузерний об’єкт CORS.

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;
}

Оскільки ви говорите, що "більшість браузерів заблокували використання міждоменного XML", я думаю, ваш сторонній сервер може не підтримувати CORS. Тоді вам доведеться знайти альтернативні підходи.

— сампатсріс
джерело
1
Чи можете ви спробувати і узагальнити вміст у посиланнях? Посилання схильні до гниття посилань, і тому не найкращий спосіб передавати інформацію про SE :)
— квітня
На жаль, третій сервер не підтримує CORS.
— аметистдрагон
4

З міркувань масштабування я хотів би зберегти навантаження сервера якомога менше

Я думаю, що це більш-менш вказує на відповідь. Надання чи не надання попередньо оброблених даних клієнту чи ні, головним чином залежить від:

  1. різниця щодо руху
  2. на ефективність впливу обробки
  3. вплив різного формату даних на клієнта

Якщо XML порівняно невеликий або є лише кілька запитів, може бути сенс просто переслати його клієнту і забути його. Те ж саме, коли попередньо оброблені дані залишаються значною частиною вихідних даних, або якщо клієнт не в змозі отримати великий прибуток від іншого формату даних (наприклад, JSON).

Однак якщо клієнт бореться з обробкою великого набору даних XML або якщо клієнту потрібна лише невелика частина вихідних XML-даних, то може бути доцільним зробити деяку попередню обробку на стороні сервера.

Врешті-решт, масштабування сервера простіше, ніж масштабування клієнта / браузера або наявної пропускної здатності. Якщо сказати в одному реченні, це залежить від того, де знаходиться вузьке місце в системі.

— JensG
джерело
+1, і додавання - перевірити ефективність у різних ситуаціях.
— SeraM
0

Мій вибір буде кешувати і стискати (викидати непотрібну інформацію) та результати gzip в браузер клієнта, ваш варіант №2 . Оскільки браузери, як правило, не є високоякісними процесорами, а сервер для мережевих ліній браузера обмежений. Я говорю про мобільних клієнтів . Якщо ви не плануєте підтримувати мобільних клієнтів, тоді вибирайте все простіше, наприклад, кількаGoogle:CORS proxy

— xmojmr
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.