Це "анти-візерунок", і чи варто його припиняти, чи це розумний дизайн?

Я в основному дивився на те, щоб зробити наступне під час створення служби REST:

1. HTML запитується
2. служба повертає потрібну веб-сторінку, але без запитуваного "ресурсу", наприклад. дані
3. веб-сторінка містить JavaScript, який видає запит AJAX до тієї ж служби (різного типу вмісту)
4. сервіс потім повертає фактичні дані (JSON) і на сторінці відображає їх

З одного боку це здається неефективним (2 запити), але тоді я використовував це, "продуктивність не викликає занепокоєння", тобто внутрішній додаток з низьким трафіком та веб-сайти прості та швидко завантажуються.

Причиною цього я є те, що веб-сторінка тоді може бути майже чистою Html + JavaScript, і майже не потрібні речі на стороні сервера, особливо без циклів, для створення таблиць і подібних матеріалів (що, на мою думку, дуже некрасиво порівняно з такі речі, як slickgrid), наприклад, розділення даних та перегляду.

Тепер, перш ніж перейти до використання цього, це гарна ідея чи я просто повинен перестати це робити?

Якщо ви запитуєте ресурс і він не містить даних, це не служба REST. Сервіс, що надає фактичні дані в json, може бути, але частина HTML це не так. Для веб-додатків це не має значення.

Методика працює, але вам потрібно знати про її обмеження:

1. Пошукові системи не інтерпретують JavaScript, тому сайт, реалізований так, не буде індексуватися Google і подібними. Для внутрішнього застосування це не має значення, для людей, які стикаються з цим, це мало би значення.
2. Користувачі з особливими потребами (як, наприклад, термінали Braille) використовують спеціальні браузери, які є досить обмеженими та можуть не правильно інтерпретувати JavaScript.

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

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

І ні, я не думаю про PHP; це найменш спроможна система шаблонів (хоча є кілька кращих, побудованих поверх неї). Я думаю, що Genshi або XSLT або щось ще більш досконале, що надає веб-віджети.

У цьому немає нічого поганого, якщо ви переконайтеся, що ви чітко структуруєте код. Ви навіть можете подавати статичний вміст, наприклад, з Apache, а не з веб-служби.

Це хороша практика. І це робиться весь час, althogugh, як вказує @JanHudec, називати це послугою REST неправильно. Але багато веб-сайтів роблять саме це саме з тих причин, які ви вказали.

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

Клієнт починається як розріджений DOM, перетягує деякі дані за допомогою XHR (іноді через JSONP) і, нарешті, приєднується до сервера socket. Ще більш базовим прикладом може бути додаток для чату.

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

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

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

як сказав @Jan Hudec, ваш підхід точно не можна назвати REST. Хоча та частина, де клієнт може просити ресурс. Краще, якщо клієнт обробляє презентаційну частину, як backboneце робить. Він спілкується з REST-сервером щодо ресурсів та відображає їх за допомогою views.

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

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

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

Те, що ти робиш, добре звучить! Однак якщо ваші відповіді json містять будь-який HTML, ви витрачаєте час.

Інший момент, хоча ваш німий клієнт, ймовірно, повинен отримувати свої дані json від іншого проекту. Ви повинні прагнути до належного розмежування між клієнтом і сервісом, тоді ви будете мати належний RESTful сервіс