REST XSLT. RESTful проекты на XSLT в условиях неполной поддержки XSL

Хочу рассказать о применении XSLT в RESTful проектах. Вопрос «Что это такое?» является основной темой презентации.

Я сделаю краткий экскурс для людей-шаблонизаторов по использованию XSLT в качестве шаблонизатора. Я не считаю, что XSLT — это шаблонизатор. В проблемы XSLT, в первую очередь, записывают вычислительные нагрузки на сервер. Клиентской обработки XSLT все боятся, потому что нет нормальной поддержки браузеров. Относительно данных, если мы их хотим отдавать, к примеру, клиенту, то они должны быть, как минимум, безопасными. Dump таблицы пользователей, как минимум, не должны содержать пароль. Сериализация данных — это проблема для небольшого количества людей. Она актуальна в контексте lazy evaluation, ленивых вычислений. Встроенные шаблонизаторы perl позволяют сделать данные рефлекторными и вычислять их по необходимости, по конечному запросу из шаблона. Это достаточно эффективно. Например, у нас такая практика использовалась. Когда мы начали переходить на XSLT, нам было обидно, что от этого придется отказаться. В конце концов, нам удалось найти промежуточное решение. Именно о нем я хочу рассказать.

Что такое REST? Это REpresentational State Transfer. Это основа нашего Web, которое, к сожалению, достаточно сильно искажается Web-разработчиками. С этим что-то хочется сделать.

Архитектурные принципы — это непосредственно тот факт, что каждая функция Web-приложения должна быть обусловлена ресурсом. Ресурс — это какой-то конкретный URL. Если XSLT — это преобразование, и если это функция, то у XSLT-преобразований — это точно такой же источник функционала, точно такой же ресурс, и он должен иметь URL.

Доступ к ресурсам обеспечен единым интерфейсом, транспортным протоколом. Понятие REST гораздо глобальнее, но, в контексте Web'а, чаще всего транспортным протоколом выступает http.

XSL — это XML документ, описывающий правила трансформации XML документов. Он может быть применен для описания представлений данных и в простейшем случае выступает в роли шаблона, или шаблонизатора XSLT. Я считаю, что его применение этим далеко не ограничивается.

Зачем нужен REST? Я задумывался над этим непосредственно по вопросам кеширования, масштабируемости, универсальности, сводимости к гиперссылкам. В контексте использования XSLT, эти факторы начинают играть, с моей точки зрения, ключевую роль.

Зачем нужен XSLT? XSLT документы могут иметь URL, а это является необходимым условием RESTful-проектов вообще. Это понятие красоты проекта.

Мощность XSLT. Функционально XSLT превосходит любой шаблонизатор. Сам шаблонизатор не может реализовать цепочные преобразования данных, свойство суперпозиции XML. Ссылались на perl, любые другие внутриязыковые преобразования, это будет не роль шаблонизатора, а будет программирование. Возможности шаблонизатора, тем не менее, остаются ограниченными.

Более подробно о проблемах XSLT. Безопасность данных. Сериализация невозможна с lazy evaluation. У сервера я бы добавил еще одну проблему: REST-преимущества не используются, если XSLT используется в качестве шаблонизатора. Грубо заменяется какой-то контекстный языковой шаблонизатор, например, это распространенно в perl. Он просто заменяется на XSLT, а парадигма проекта построения не меняется. Это плохо.

Если мы хотим и решили применять XSLT, то мы имеем некоторые недостатки, было бы логично получить и преимущества. Я хотел бы рассказать о преимуществах и о том, как их получить.

У клиента, кроме неполной поддержки браузерами, есть еще проблема непрозрачности для поисковых систем. По факту, если поисковая система сталкивается с клиентским XSLT, она видит XML-данные, которые в некоторых случаях являются инструкциями, откуда нужно взять данные и какие преобразования произвести. Она их не производит и видит сайт-пустышку. Такая проблема есть, в частности. Я хочу предложить ее решение.

Здесь показана основа, принцип решения. Стандартная ситуация. Шаблонизатор. Данные, где бы они ни хранились, обычно в СУБД, являются плоскими, попадают в логику скрипта. При взаимодействии со встроенным шаблонизатором у данных есть возможность оставаться объектными, применять ленивые вычисления, lazy evaluation, оставаться рефлекторными. Во время работы шаблонизатора контакт с логикой не теряется. Это могут быть вызовы функций, хотя это плохо. Это может быть именно вычисление по запросу, что уже лучше. Тем не менее, преимущество есть. Мы его теряем, когда переходим к схеме использования XSLT в качестве шаблонизатора. Здесь можно видеть, что плюсов мы, фактически, никаких не получаем, но мы явно теряем возможность взаимодействия на этапе шаблонизации, на этапе обработки превращения данных в представления. XML — это, фактически, сериализованные данные. Lazy evaluation, или какое-то другое взаимодействие с логикой скрипта, на этот момент становится невозможным.

Я призываю использовать XSLT именно так, как он, на мой взгляд, был задуман. А именно, использовать его исключительно в контексте REST. Мы уже пришли к использованию XSLT.

Какую схему расширений я предлагаю? Я предлагаю просто добавить еще один пункт «Генератор XML». Это каким-либо образом организованный скрипт, предпочтительно отдельно вынесенный функционал на нативном языке программирования логики. В этом случае, как и в первом, сохраняется возможность связи логики и генератора XML. Единственная функция генератора XML — обеспечить безопасность данных, потому что дальше этот XML должен обрести свойства безопасности, в отличие от второго варианта.

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

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

Учитывая то, что на сегодняшний день клиент и поисковая система не способны это обрабатывать, но при применении REST XSLT начинают использоваться явные преимущества REST XSLT, я предлагаю использовать просто элементарный серверный прокси XSL-шлюз, который получает запросы от браузеров, определяет, способен ли браузер обработать XSLT. Это не такая большая проблема. В случае, если это поисковик, ему отдается html, если это браузер, ему тоже отдается html, старый, html браузера. Если это XSLT, то форвардятся входящие данные.

На этом слайде показано, как картина должна выглядеть в комплексе. Это стандартная ситуация. Есть статика, есть динамика, генерируется с возможностью объектного взаимодействия. Это все сливается через http-сервер. На этом уровне мы имеем XSLT REST. Каждый ресурс, статичный или динамичный, или сами шаблоны, имеют URL.

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

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

XSLT шлюз — это: REST XSLT уже сегодня. Компенсация серверных нагрузок за счет того, что большинство браузеров уже сегодня поддерживает клиентский XSLT. Сервер разгружается, но вы имеете возможность использовать XSLT. Компенсация недостатков браузеров, которые еще не способны в полном объеме что-либо делать. Сам XSLT-шлюз является расширяемой платформой. Например, FORCE_XSLT может быть флагом, который даст возможность обрабатывать небезопасные серверные преобразования, если не удалось обеспечить безопасность XML, хотя это плохо, или чтобы никто не узнал, что внутри REST XSLT. Еще можно использовать серверный кеш XSLT на основе http. В случае сложных архитектур, когда XSLT выступает в роли шаблонизатора, вопрос кеша, за неимением простой реализации, откладывается на потом. Главное преимущество REST и XSLT — что кешировать уже готовые, посчитанные преобразования XML и XSLT, если ни XSLT, ни XML не менялись, технически оказывается весьма проблематично. Если у нас есть layer REST, то на уровне серверных преобразований мы имеем возможность кешировать. Несколькими строками кода добавить кеш, и все это будет замечательно работать.

Из дополнительных идей сама идея XSLT шлюза позволяет расширить ее на любые другие новые технологии, которые сейчас на клиентах не поддерживаются. Например, вы можете иметь свои изображения в формате SVG. В случае если шлюз определяет, что браузер способен отобразить SVG, то его передавать, если нет — производить трансформацию в GIF, естественно, используя REST с кешированием. Получается прозрачная и высоковыразительная система. Сам XSLT-шлюз — это всего пара страниц исходного кода. Это еще одно преимущество. Это прозрачная, готовая компонента. Как бы она ни была реализована, она обеспечивает достаточную производительность и позволяет раскрыть ряд преимуществ XSLT.

Вопрос: Расскажите подробнее о RESTful-проектах.

Павел: Максимально подробно REST раскрывает Wikipedia. Сам термин RESTful взят оттуда же. RESTful-проект — это проект, который в большей степени соответствует концепции REST. Сама его концепция неразрывно связана с появлением Web. Для того чтобы понять, что такое REST, его нужно чему-то противопоставить. Его обычно противопоставляют RPC. REST расценивает функционал как ресурсы. CORBA, или вообще любой RPC, расценивает функционал как удаленный вызов к функции. REST противопоставляет себя RPC, по крайней мере, в рамках Wikipedia.

Вопрос: Правильно ли я понял, что для XSLT-преобразований на стороне браузера и на стороне XSLT шлюза используются одни и те же XSLT шаблоны?

Павел: Да, шаблоны одни и те же.

Вопрос: Не все браузеры поддерживают? И XSLT-преобразования на стороне разных браузеров реализованы по-разному?

Павел: Не все браузеры поддерживают. XSLT-шлюз имеет возможность быть настолько лояльным по отношению к браузерам, ровно настолько параноидальным одновременно, насколько вы это хотите позволить. Я изначально рекомендую собрать схему, которая показана на слайде «REST XSLT: реализация» с XSLT шлюзом, который всегда обрабатывает на стороне сервера. Первое, что нужно сделать — это REST XSLT layer. Браузеры будут обрабатывать XSL с точностью до поддержки ими функциональности. Например, Opera 9 не поддерживает document, в Internet Explorer есть MSXSL, а в Firefox есть EXSL.

Вопрос: Как согласуется преобразование на стороне браузера с тем фактом, что сейчас все больше Web-приложений переходят в сторону богатых JavaScript аппликаций, когда на стороне клиента выполняется масса JavaScript, например Ajax и т.д.? Вы говорили, что клиенты нас похвалят за то, что мы им сделали меньше трафика. Но мы им увеличили на порядок процессорное время. Они нам за это спасибо скажут?

Павел: Я не видел ни одного сайта, который с помощью JS или XSLT преобразований умудрился бы задержать время загрузки страницы до ощутимого предела. XSLT преобразования на стороне клиента занимают примерно столько же времени, сколько это делается на стороне сервера, потому что мощности клиента и сервера сравнимы.

Вопрос: Что такое безопасный XML?

Павел: XML-данные, которые идут, в случае шаблонов XSLT, из логики в шаблонизаторе, или из логики в XSLT небезопасны. Элементарно: это выгрузка данных вместе с секретными, которые идут в шаблоны. Уже шаблоны показывают именно те данные, которые можно показать пользователю. Такая абстракция недопустима в случае REST XSLT. Например, если мы делаем выборку из таблицы пользователя, там может идти достаточно большое количество данных, которое не должно уходить. Полные dump’ы делать нельзя.

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.