Що насправді не в тому, що кінцева точка повертає HTML, а не дані JSON?

Коли я вперше почав вивчати PHP (приблизно 5 або 6 років тому), я дізнався про Ajax , і пройшов "фази":

1. Сервер повертає дані HTML , і ви помістіть його в DOM в innerHTML
2. Ви дізнаєтесь про формати передачі даних, такі як XML (і кажете "ооо, для чого це використовується)", а потім JSON.
3. Ви повертаєте JSON і створюєте свій інтерфейс, використовуючи код ванільного JavaScript
4. Ви переходите до jQuery
5. Ви дізнаєтесь про API, заголовки, коди статусу HTTP, REST , CORS та Bootstrap
6. Ви вивчаєте SPA та фреймворки ( React , Vue.js та AngularJS ) та стандарт API JSON.
7. Ви отримуєте деякий застарілий код підприємства і, перевіривши його, виявите, що вони виконують те, що описано в кроці 1.

Під час роботи з цією базовою базою кодів я навіть не вважав, що вона може повернути HTML (я маю на увазі, ми зараз професіонали, правда?), Тому мені важко було шукати кінцеву точку JSON, яка повертала дані, які дзвінки Ajax заповнюються. Лише я не запитав "програміста", що він сказав мені, що він повертає HTML і додається безпосередньо до DOM за допомогою внутрішнього HTMLML.

Звичайно, це було важко прийняти. Я почав думати про способи перевстановити це в кінцеві точки JSON, думаючи про тестування одиниць кінцевих точок тощо. Однак ця кодова база не має тестів. Ні одного. І це понад 200 тис. Ліній. Звичайно, одне з моїх завдань - запропонувати підходи до тестування всього, але наразі ми цього ще не вирішуємо.

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

Що саме не так у цьому?

Що насправді не в тому, що кінцева точка повертає HTML, а не дані JSON?

Нічого, насправді. Кожна програма має різні вимоги, і можливо, ваша програма не була розроблена як SPA.

Можливо, ці прекрасні рамки, які ви цитували (Angular, Vue, React, і т. Д.), Були недоступні під час розробки, або не були "схвалені" підприємці, які використовувались у вашій організації.

Я розповім вам про це: кінцева точка, яка повертає HTML, зменшує вашу залежність від бібліотек JavaScript і зменшує навантаження на браузер користувача, оскільки йому не потрібно буде інтерпретувати / виконувати JS-код для створення об’єктів DOM - HTML вже є, це лише питання розбору елементів та їх надання. Звичайно, це означає, що ми говоримо про розумний обсяг даних. 10 мегабайт даних HTML не є розумним.

Але оскільки у поверненні HTML немає нічого поганого, те, що ви втрачаєте, не використовуючи JSON / XML - це в основному можливість використання вашої кінцевої точки як API. І тут криється найбільше питання: чи дійсно потрібно бути API?

Пов’язано: чи добре повертати HTML з API JSON?

JSON та HTML виконують дві різні семантичні цілі.

Якщо ви заповнюєте веб-сторінку даними, використовуйте JSON. Якщо ви створюєте веб-сторінку з частин веб-сторінок, використовуйте HTML.

Вони можуть якось звучати так, ніби вони одне й те саме, але це зовсім не так. По-перше, коли ви створюєте частину веб-сторінки за допомогою HTML, повернутого сервером, ви працюєте на стороні сервера. Коли ви прив'язуєте дані до веб-сторінки, ви працюєте на стороні клієнта.

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

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

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

Я думаю, у вас це трохи назад. Ти кажеш:

у нас немає жодного тесту, тому у нас немає конкретних причин для створення цієї кінцевої точки JSON

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

200k рядків коду багато для рефактора і, ймовірно, важко підтримувати. Визначення деяких кінцевих точок та тестування їх може бути гарним місцем для початку.

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

Існує 3 способи (принаймні?) Для створення веб-сторінки:

• Створіть всю сторону сервера сторінки.
• Поверніть сторінку з голими кістками з сервера плюс код (JavaScript), і перейдіть на сторінку, щоб отримати її дані та передати в клієнтську сторону HTML.
• Поверніть часткову сторінку плюс код і отримайте коди заздалегідь відредаговані блоки HTML, які він може потрапити на сторінку.

Перший - чудово. Другий - теж добре. Саме в цьому і полягає проблема.

Причина проста: тепер ви розділили конструкцію HTML-сторінки на повністю відключені частини. Проблема полягає в обслуговуванні. Тепер у вас є дві окремі організації, які відповідають за керування деталями інтерфейсу користувача. Тож вам доведеться синхронізувати CSS та інші подібні деталі між двома окремими фрагментами. Ви змінили ширину бічної смуги? Чудово. Тепер фрагмент HTML, який повертається, викликає горизонтальне прокручування, оскільки його припущення щодо ширини бічної смуги більше не втримуються. Ви змінили колір тла для цього блоку? Чудово, тепер колір шрифту вашого фрагмента HTML стикається, оскільки він надавав інший колір фону, і хтось забув перевірити цю кінцеву точку.

Справа в тому, що ви зараз розділили знання, які повинні бути централізовані в одному місці (а саме логіка презентації), і це ускладнює переконання, що всі частини правильно поєднуються. Використовуючи API JSON, ви можете замість цього зберегти всю цю логіку лише на передньому кінці, або ви можете зберегти це у шаблонах на стороні вашого сервера, якщо ви перетворите свої дані в HTML. Йдеться про збереження знань / логіки презентації в одному місці, тому нею можна керувати послідовно та як частину одного процесу. HTML / CSS / JS досить складно тримати прямо, не розбиваючи його на безліч крихітних шматочків.

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

Я б сказав, що нічого поганого в тому, що сервер повертає фрагмент HTML і користувальницький інтерфейс призначає його .innerHTML якогось елемента. Це, на мій погляд, найпростіший спосіб розробити асинхронний код JavaScript. Перевага полягає в тому, що якомога менше робиться за допомогою JavaScript і якомога більше робиться в контрольованому бэк-енді. Пам’ятайте, що підтримка JavaScript у веб-переглядачах різниться, але ваш бек-енд завжди має одну і ту ж версію компонентів, що означають, що робити якомога більше в бек-енді буде означати якомога менше несумісностей версій.

Тепер, іноді ви хочете більше, ніж просто фрагмент HTML. Наприклад, код стану та фрагмент HTML. Тоді ви можете використовувати об’єкт JSON, який має два члени, статусCode та HTML, з яких другий може бути призначений .innerHTML деякого елемента після перевірки statusCode. Отже, використання JSON та використання innerHTML жодним чином не є альтернативними ексклюзивними підходами; їх можна використовувати разом.

Використовуючи JSON, ви навіть можете мати кілька фрагментів HTML в одній відповіді, які присвоюються .innerHTML з декількох елементів.

Підсумовуючи: використовуйте .innerHTML. Це робить ваш код сумісним із якомога більшою кількістю версій браузера. Якщо вам потрібно більше, використовуйте JSON та .innerHTML разом. Уникайте XML.

В принципі немає нічого поганого . Питання: чого ви хочете досягти?

JSON ідеально підходить для передачі даних. Якщо ви надсилаєте HTML замість цього і очікуєте, що клієнт витягне дані з HTML, це сміття.

З іншого боку, якщо ви хочете передати HMTL, який буде наданий як HTML, тоді надішліть його як HTML - замість упаковки HTML у рядок, перетворивши рядок у JSON, передаючи JSON, розшифрувавши його з іншого боку , отримання рядка та вилучення HTML з рядка.

І якраз вчора я зіткнувся з кодом, який поставив два елементи в масив, перетворив масив у JSON, поклав JSON в рядок, поклав рядок всередину масиву, перетворив весь масив у JSON, відправив його клієнту, який розшифрував JSON, отримав масив, що містить рядок, взяв рядок, витяг JSON з рядка, розшифрував JSON і отримав масив з двома елементами. Не робіть цього.

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

У сучасному додатку код API повинен відповідати за дані, а клієнтський код повинен відповідати за презентацію.

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

Якщо ваш API поверне JSON або іншу форму чистих даних, він стане набагато кориснішим. Існуюча програма все ще може споживати ці дані та представляти їх належним чином. Тепер, однак, інші речі можуть використовувати API для доступу до тих же даних. Знову ж, обслуговування простіше - весь HTML знаходиться в одному місці, тому, якщо ви хочете змінити стиль всього сайту, вам не потрібно змінювати API.

HTML прив’язаний до конкретного дизайну та використання.

За допомогою HTML, якщо ви хочете змінити макет сторінки, вам потрібно змінити спосіб генерування html при виклику сервера. Зазвичай для цього потрібен бек-енд програміст. Тепер у вас є бек-енд-програмісти, які за визначенням не є вашими кращими html-сценаристами, які обробляють ці оновлення.

Якщо JSON змінить макет сторінки, існуючий виклик сервера JSON не обов’язково повинен взагалі змінюватися. Натомість ваш розробник, або навіть дизайнер, оновлює шаблон, щоб створити різний HTML, який ви хочете, з тих самих основних даних.

Крім того, JSON може стати основою для інших послуг. У вас можуть бути різні ролі, яким потрібно бачити однакові основні дані по-різному. Наприклад, у вас може бути веб-сайт клієнта, який відображає дані про товар на сторінці замовлення, і внутрішня сторінка продажів для повторень, яка показує ті самі дані в зовсім іншому макеті, можливо поряд із деякою іншою інформацією, недоступною для загальних клієнтів. З JSON один і той же виклик сервера може використовуватися в обох видах перегляду.

Нарешті, JSON може покращити масштаб. Останніми роками ми начебто зайшли за борт із рамками JavaScript на стороні клієнта. Я думаю, що настав час фактично зробити крок назад і почати думати про те, який JavaScript ми використовуємо, і як це впливає на продуктивність браузера ... особливо на мобільних пристроях. Це означає, що якщо ви використовуєте веб-сайт, достатньо великий для того, щоб вимагати ферму серверів або кластер, замість одного сервера, JSON може краще масштабувати. Користувачі нададуть вам час на обробку у своїх браузерах безкоштовно, і якщо ви скористаєтесь цим, ви зможете зменшити завантаження сервера у великому розміщенні. JSON також використовує меншу пропускну здатність, тому, якщо ви досить великийі використовувати його належним чином, JSON помірно дешевше. Звичайно, це також може бути гіршим, якщо ви в кінцевому підсумку подаєте 40 КБ бібліотекам для розбору 2 КБ даних на 7 КБ html, тож знову: вам варто знати, що ви робите. Але потенціал JSON є для покращення продуктивності та витрат.

Немає нічого поганого в такій кінцевій точці, якщо вона відповідає її вимогам. Якщо потрібно виплюнути HTML, щоб відомий споживач міг ефективно аналізувати, впевнений, чому б ні?

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

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

Тепер, якщо ви переконайтеся, що ваш html сумісний з xml, то ви золото.

Зважаючи на це, у мене є значна проблема з цим:

Я розповім вам про це: кінцева точка, яка повертає HTML, зменшує вашу залежність від бібліотек JavaScript і зменшує навантаження на веб-переглядач користувача, оскільки йому не потрібно буде інтерпретувати / виконувати JS-код для створення об’єктів DOM - HTML вже є, це лише питання розбору елементів та їх надання. Звичайно, це означає, що ми говоримо про розумний обсяг даних. 10 мегабайт даних HTML не є розумним.

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

Тут ви поєднуєте ці два з метою швидкого виконання коду JS. І це мікрооптимізація.

Я ніколи не бачив це як гарну ідею, за винятком дуже тривіальних систем.

Моя порада? Не робіть цього. HC SVNT DRACONES , YMMV тощо.

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

У PHP ви просто використовуєте, json_encode($data)і клієнт з іншого боку розбирає його. А коли ви отримуєте дані JSON з веб-сервісу, ви просто використовуєте, $data=json_decode($response)і ви можете вирішити, як використовувати дані, як би ви робили зі змінними.

Припустимо, ви розробляєте додаток для мобільного пристрою, навіщо вам потрібен формат HTML, коли мобільні додатки рідко використовують веб-браузер для аналізу даних? Багато мобільних додатків використовують JSON (найпоширеніший формат) для обміну даними.

Враховуючи, що мобільні телефони часто розміщуються на дозованих планах, чому ви хочете використовувати HTML, який займає набагато більше пропускної здатності, ніж JSON?

Навіщо використовувати HMTL, коли HTML обмежений своїм словником і JSON може визначати дані? {"person_name":"Jeff Doe"}є більш інформативним, ніж HTML може надавати про свої дані, оскільки він визначає лише структуру для парсерів HTML, а не визначає дані.

JSON не має нічого спільного з HTTP. Ви можете помістити JSON у файл. Ви можете використовувати його для конфігурацій. Композитор використовує JSON. Ви можете використовувати його для збереження простих змінних у файлах.

Класифікувати право чи неправильно важко. ІМО, питання, які я задаю, - це "чи варто ", або "чи можна це робити з меншим? ".

Кожна кінцева точка повинна прагнути до спілкування з якомога меншим вмістом. Співвідношення сигнал / шум, як правило, коди HTTP <JSON <XHTML. У більшості ситуацій добре обирати найменш галасливий протокол.

Я розходжуюсь щодо питання щодо завантаження клієнтського браузера від @machado, так як для сучасних браузерів це не проблема. Більшість із них оснащені хорошим поводженням з кодами HTTP та відповідями JSON. І хоча ви зараз не маєте тестів, тривале обслуговування менш галасливого протоколу було б дешевше, ніж вище.