Это «анти-паттерн» и я должен прекратить его использовать или это умный дизайн?

10

Я в основном старался сделать следующее при создании службы REST:

HTML запрашивается
Сервис возвращает нужную веб-страницу, но без запрошенного «ресурса», например. данные
веб-страница содержит JavaScript, который выдает запрос AJAX к одному и тому же сервису (другой тип контента)
Затем сервис возвращает фактические данные (JSON), и страница отображает их

С одной стороны это кажется неэффективным (2 запроса), но тогда, когда я использовал это, «производительность не имеет значения», то есть внутреннее приложение с низким трафиком и веб-сайты просты и быстро загружаются.

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

Теперь, прежде чем я начну использовать это, это хорошая идея или я должен просто прекратить это делать?

web-services rest anti-patterns

— beginner_
источник

2

Если вы хотите проводить больше времени со своими близкими, и вы хотите иметь свободное время, чтобы наслаждаться хобби или преследовать личные цели, то ради Бога: не программируйте такие приложения! Но если вам нравится оставаться поздно ночью и выходными в офисе, поддерживая тонны «умного» кода, тогда подойдет.

— Тулаинс Кордова

3

Можете ли вы конкретно уточнить, что вы считаете плохим? Контекст: это не зверь на 10 млн. LOC, который важен для бизнеса. Это больше похоже на <5000 LOC и не имеет значения, если оно не работает в течение нескольких дней. Да, это не то, что я должен делать дрянные вещи, следовательно, излагайте то, что вы считаете таким плохим.

— beginner_

@begginer_ Каждое программное обеспечение начинается с малого. То, что вы описываете, напоминает Машину Рубе Голдберга: молоток бьет человека, человек бросает печенье, попугай захватывает печенье и наклоняет вазу и т. Д.

— Tulains Córdova

Причина, по которой это делается, часто заключается в повышении производительности, когда выборка данных может быть выполнена с помощью нескольких одновременных запросов на разные серверы. Не похоже, что это применимо в вашем случае.

— user16764

Как вы используете этот сервис от клиентов, таких как скрипты, или от curl? У этих вещей нет интерпретаторов JavaScript. Это только для браузера?

— Брайан Оукли

17

Если вы запрашиваете ресурс, и он не содержит данных, то это не сервис REST. Служба, предоставляющая фактические данные в json, может быть, но часть HTML - нет. Для веб-приложения это не имеет значения.

Техника работает, но вы должны знать о ее ограничениях:

Поисковые системы не интерпретируют JavaScript, поэтому сайт, созданный таким образом, не будет индексироваться Google и подобными. Для внутреннего применения это не имеет значения, для публичного - очень важно.
Пользователи с особыми потребностями (например, те, которые используют терминалы Брайля) используют специальные браузеры, которые довольно ограничены и могут неправильно интерпретировать JavaScript.

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

Вы можете и должны сохранять разделение данных и отображение на стороне сервера. Система шаблонов может и должна просто принимать данные как структуру данных или даже json (особенно, если реальная служба работает на другом языке, чем система шаблонов) и просто расширять шаблон с этими данными.

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

— Ян Худек
источник

Я пишу толстые клиенты на JavaScript, которые делают именно это. Но это, вероятно, плохая идея для обычных сайтов.

— K ..

Почему это не ОТДЫХ?

— dagnelies

1

Если вы различаете «данные», которые формируют приложение (HTML, JS, CSS и т. Д.), И «данные», которые приложение отображает (JSON), часть JSON является REST, но часть, которая загружает «код», не является т. Если вы видите все это более абстрактно, то оба.

— K ..

2

В этом нет ничего плохого, если вы будете правильно структурировать свой код. Вы можете даже обслуживать статический контент, например, с Apache, а не с вашего веб-сервиса.

— Стивен Шланскер
источник

2

Apache - излишний запас статического контента. Есть гораздо более быстрые серверы. Самым популярным кажется Nginx .

— Ян Худек

5

Это был пример, не более того.

— Стивен Шланскер

2

Это хорошая практика. И это делается постоянно, хотя, как указывает @JanHudec, называть это REST-сервисом неправильно. Но многие сайты делают именно это по причинам, которые вы указали.

— Росс Паттерсон
источник

1

... и главная причина, по которой многие это делают, заключается в том, что взаимодействие с данными в любом случае происходит через сервисы / JSON , поэтому, вероятно, лучше обрабатывать все ваши взаимодействия с данными одинаково. (то есть, если вы используете AJAX для обновления таблицы ... вы должны также использовать его для создания таблицы в первую очередь.)

— Чад Томпсон,

@ChadThompson Да, я нахожу, что большую часть времени, если я не создаю такие вещи, во-первых, где-то внизу я получаю запрос на функцию динамического обновления страницы на основе того, что клиент делает что-то - что означает, что простая реализация теперь приводит к тому, что и клиент, и сервер знают, как создать страницу. Во-первых, проще просто построить его на клиенте.

— Такрой

1

Я бы не назвал это анти-паттерном, который вы описываете как более или менее толстый клиент , не совсем в отличие от таких сервисов, как Trello. Первоначальная обязанность сервера - отправить DOM и все ресурсы, необходимые для работы клиента. Я работал над аналогичными проектами в области автоматизации центров обработки данных и мониторинга сети.

Клиент запускается как разреженный DOM, получает некоторые данные через XHR (иногда через JSONP) и, наконец, подключается к серверу сокетов. Еще более простой пример - приложение для чата.

Единственная причина не делать этого - то, что это может быть чрезвычайно трудно понять правильно. Если вы знакомы с асинхронным функциональным программированием и всеми расами и другими проблемами, которые он может представлять, у вас не возникнет проблем с его поддержкой. Что еще более важно, у вас не будет проблем с написанием этого, чтобы другие люди могли в конечном итоге поддерживать его.

Если мысль о добавлении дополнительных функций начинает пугать вас, или вы начинаете находить, что отладка - это кошмар, то вы можете рассмотреть другие методы в процессе разработки, продолжая экспериментировать и изучать.

Это правильный дизайн, если вы не копаете яму для себя. Если у вас повсюду есть множество случайных JS вместо чистого интерфейса, то вы, вероятно, захотите пересмотреть или по-другому выполнить проект. Большинство ваших функций, которые определены для выполнения после загрузки всех ресурсов, должны быть анонимными и вводиться из чистого интерфейса. Если это не так, вы можете столкнуться с проблемой.

— Тим Пост
источник

Что вы подразумеваете под "случайным JS"? В моем случае то, что вы описываете выше, намного сложнее, чем у меня (несколько полей ввода и таблица (вкладка slickgrid) или jquery ui). Вот и все. Около 200 лок на страницу.

— beginner_

0

как сказал @Jan Hudec, ваш подход нельзя назвать REST. Хотя часть, где клиент может запросить ресурс. Лучше, если клиент обрабатывает презентационную часть, как backboneделает. Он связывается с сервером REST для ресурсов и отображает их с помощью views.

— Broncha
источник

0

Это может быть анти-паттерном, но я думаю, что это также будущее веб-приложений. Однако вместо того, чтобы разбираться с JavaScript, вы должны по крайней мере использовать библиотеку шаблонов. Лучшее решение - клиентская MVC-инфраструктура, такая как AngularJS (которую я сейчас использую).

Вот еще несколько ссылок: популярное сообщение в блоге, в котором сравниваются несколько фреймворков, а также сайт, который реализует одну и ту же программу с использованием нескольких фреймворков.

Также: комментарии Яна Худека о взаимодействии с поисковыми системами и средствах чтения с экрана являются действительными. Если вы работаете на сайте электронной коммерции (где имеет значение pagerank), вы, вероятно, не хотите использовать клиентские платформы. Но для внутренних приложений это обычно не проблема.

— Парсифаль
источник

thx никогда не слышал об AngularJS. Но я думаю, что для моих текущих потребностей это слишком много.

— beginner_

0

То, что ты делаешь, звучит хорошо! Однако, если ваши ответы json содержат какой-либо HTML, вы теряете время.

Другой момент, однако, заключается в том, что ваш тупой клиент должен, вероятно, получать свои данные json из другого проекта. Вы должны стремиться к правильному разделению между клиентом и сервисом, тогда у вас будет правильный сервис RESTful

— Кит Пинкомб
источник