Я в основном старался сделать следующее при создании службы REST:
- HTML запрашивается
- Сервис возвращает нужную веб-страницу, но без запрошенного «ресурса», например. данные
- веб-страница содержит JavaScript, который выдает запрос AJAX к одному и тому же сервису (другой тип контента)
- Затем сервис возвращает фактические данные (JSON), и страница отображает их
С одной стороны это кажется неэффективным (2 запроса), но тогда, когда я использовал это, «производительность не имеет значения», то есть внутреннее приложение с низким трафиком и веб-сайты просты и быстро загружаются.
Причина, по которой я пришел к этому, заключается в том, что веб-страница может быть почти чистым Html + JavaScript, и для создания таблиц и тому подобного почти не требуется никаких серверных вещей, особенно никаких циклов (что я считаю очень уродливым по сравнению с такие вещи, как Slickgrid), например, разделение данных и просмотра.
Теперь, прежде чем я начну использовать это, это хорошая идея или я должен просто прекратить это делать?
web-services
rest
anti-patterns
beginner_
источник
источник
Ответы:
Если вы запрашиваете ресурс, и он не содержит данных, то это не сервис REST. Служба, предоставляющая фактические данные в json, может быть, но часть HTML - нет. Для веб-приложения это не имеет значения.
Техника работает, но вы должны знать о ее ограничениях:
Я также хотел бы отметить, что код, генерирующий HTML, в основном одинаков, независимо от того, выполняется ли он на стороне сервера или на стороне клиента. У вас гораздо больший выбор языков и фреймворков на стороне сервера, и я уверен, что есть несколько эквивалентов slickgrid.
Вы можете и должны сохранять разделение данных и отображение на стороне сервера. Система шаблонов может и должна просто принимать данные как структуру данных или даже json (особенно, если реальная служба работает на другом языке, чем система шаблонов) и просто расширять шаблон с этими данными.
И нет, я не думаю о PHP; это наименее способная система шаблонов (хотя есть и лучшие, построенные на ней). Я думаю, Genshi или XSLT или что-то еще более продвинутое, которое предоставляет веб-виджеты.
источник
В этом нет ничего плохого, если вы будете правильно структурировать свой код. Вы можете даже обслуживать статический контент, например, с Apache, а не с вашего веб-сервиса.
источник
Это хорошая практика. И это делается постоянно, хотя, как указывает @JanHudec, называть это REST-сервисом неправильно. Но многие сайты делают именно это по причинам, которые вы указали.
источник
Я бы не назвал это анти-паттерном, который вы описываете как более или менее толстый клиент , не совсем в отличие от таких сервисов, как Trello. Первоначальная обязанность сервера - отправить DOM и все ресурсы, необходимые для работы клиента. Я работал над аналогичными проектами в области автоматизации центров обработки данных и мониторинга сети.
Клиент запускается как разреженный DOM, получает некоторые данные через XHR (иногда через JSONP) и, наконец, подключается к серверу сокетов. Еще более простой пример - приложение для чата.
Единственная причина не делать этого - то, что это может быть чрезвычайно трудно понять правильно. Если вы знакомы с асинхронным функциональным программированием и всеми расами и другими проблемами, которые он может представлять, у вас не возникнет проблем с его поддержкой. Что еще более важно, у вас не будет проблем с написанием этого, чтобы другие люди могли в конечном итоге поддерживать его.
Если мысль о добавлении дополнительных функций начинает пугать вас, или вы начинаете находить, что отладка - это кошмар, то вы можете рассмотреть другие методы в процессе разработки, продолжая экспериментировать и изучать.
Это правильный дизайн, если вы не копаете яму для себя. Если у вас повсюду есть множество случайных JS вместо чистого интерфейса, то вы, вероятно, захотите пересмотреть или по-другому выполнить проект. Большинство ваших функций, которые определены для выполнения после загрузки всех ресурсов, должны быть анонимными и вводиться из чистого интерфейса. Если это не так, вы можете столкнуться с проблемой.
источник
как сказал @Jan Hudec, ваш подход нельзя назвать REST. Хотя часть, где клиент может запросить ресурс. Лучше, если клиент обрабатывает презентационную часть, как
backboneделает. Он связывается с сервером REST для ресурсов и отображает их с помощьюviews.источник
Это может быть анти-паттерном, но я думаю, что это также будущее веб-приложений. Однако вместо того, чтобы разбираться с JavaScript, вы должны по крайней мере использовать библиотеку шаблонов. Лучшее решение - клиентская MVC-инфраструктура, такая как AngularJS (которую я сейчас использую).
Вот еще несколько ссылок: популярное сообщение в блоге, в котором сравниваются несколько фреймворков, а также сайт, который реализует одну и ту же программу с использованием нескольких фреймворков.
Также: комментарии Яна Худека о взаимодействии с поисковыми системами и средствах чтения с экрана являются действительными. Если вы работаете на сайте электронной коммерции (где имеет значение pagerank), вы, вероятно, не хотите использовать клиентские платформы. Но для внутренних приложений это обычно не проблема.
источник
То, что ты делаешь, звучит хорошо! Однако, если ваши ответы json содержат какой-либо HTML, вы теряете время.
Другой момент, однако, заключается в том, что ваш тупой клиент должен, вероятно, получать свои данные json из другого проекта. Вы должны стремиться к правильному разделению между клиентом и сервисом, тогда у вас будет правильный сервис RESTful
источник