Посмотрите, например, на GitHub RESTful API. Чтобы получить информацию о репозитории, вы должны сделать запрос GET для api.github.com/repos/yegor256/rultor. В ответ вы получите документ JSON со всеми подробностями репозитория yegor256 / rultor. Попробуйте, URL-адрес не требует никакой аутентификации.
Чтобы открыть тот же репозиторий на хорошей HTML + CSS-странице, вы должны использовать другой URL-адрес: github.com/yegor256/rultor. URL-адрес отличается, серверная сторона определенно отличается, но характер данных точно такой же. Единственное, что меняется - это слой представления.
В первом случае мы получаем JSON; Во втором - HTML.
Как насчет их объединения? Как использовать тот же URL-адрес и тот же механизм обработки на стороне сервера для обоих из них? Как насчет переноса всей задачи рендеринга на сторону клиента (браузер) и предоставления серверу возможности работать исключительно с данными?
Чтобы открыть тот же репозиторий на хорошей HTML + CSS-странице, вы должны использовать другой URL-адрес: github.com/yegor256/rultor. URL-адрес отличается, серверная сторона определенно отличается, но характер данных точно такой же. Единственное, что меняется - это слой представления.
В первом случае мы получаем JSON; Во втором - HTML.
Как насчет их объединения? Как использовать тот же URL-адрес и тот же механизм обработки на стороне сервера для обоих из них? Как насчет переноса всей задачи рендеринга на сторону клиента (браузер) и предоставления серверу возможности работать исключительно с данными?
XSLT - это технология, которая может помочь нам в этом. В «XML + XSLT в браузере» я кратко объясню, как это работает в браузере. В двух словах сервер возвращает XML с некоторыми данными и ссылкой на таблицу стилей XSL. Таблица стилей, выполняемая в браузере, преобразует XML в HTML. Язык XSL так же эффективен, как и любой другой движок рендеринга, например JSP, JSF, Tiles или что у вас есть. На самом деле, он гораздо более мощный.
Используя этот подход, мы буквально удаляем весь уровень рендеринга («Вид» в парадигме MVC) с сервера и переносим его в браузер.
Если мы сможем сделать это возможным, веб-сервер предоставит только RESTful API, и на каждой странице ответов будет прикреплена таблица стилей XSL. Что мы получаем? Мы обсудим это позже, в конце поста. Теперь давайте посмотрим, с какими проблемами мы столкнемся:
В JSON нет слоя рендеринга. Для JSON нет такого понятия, как XSLT. Таким образом, нам придется забыть о JSON и остаться только с XML. Для меня это звучит отлично. Другие не любят XML и предпочитают работать только с JSON. Никогда не понимал их :)
XSLT 2.0 поддерживается не всеми браузерами. Даже XSLT 1.0 поддерживается только некоторыми из них. Например, Internet Explorer 8 вообще не поддерживает XSLT.
Браузеры поддерживают только методы GET и POST HTTP, в то время как традиционный эксплойт API RESTful также, по крайней мере, PUT и DELETE.
Первая проблема не является проблемой. Это просто вопрос вкуса (и уровня образования). Последние две проблемы гораздо серьезнее. Давайте обсудим их.
Трансформация XSL на сервере
Некоторые браузеры не поддерживают XSLT. Как мы решаем это?
Я думаю, что лучший подход - это проанализировать HTTP-заголовок User-Agent в каждом запросе и выяснить, поддерживает ли эта версия браузера XSLT или нет. Это не так сложно сделать, так как эта информация о совместимости является общедоступной.
Если браузер не поддерживает XSLT, мы можем выполнить преобразование на стороне сервера. У нас уже есть XML с данными, сгенерированными сервером, и у нас уже есть подключенный к нему XSL. Все, что нам нужно сделать, это применить последнее к первому и получить HTML-страницу. Затем мы возвращаем HTML-код в браузер.
Кроме того, мы также можем обратить внимание на заголовок Accept. Если он установлен в application / xml или text / xml, мы возвращаем XML, независимо от того, что говорит User-Agent. Это означает, в основном, что с нами обращается некоторый клиент API, а не браузер. И этот клиент не заинтересован в HTML, но в чистых данных в формате XML.
POST вместо PUT
Для этого не существует обходного пути. Браузеры ничего не знают о PUT или DELETE. Таким образом, мы должны также забыть их в наших API-интерфейсах RESTful. Мы должны разработать наш API, используя только два метода: GET и POST. Возможно ли это? Да. Почему нет? Это не будет выглядеть так, как при всех шести методах (некоторые API-интерфейсы также используют OPTIONS и HEAD), но он будет работать.
Что мы получаем?
Хорошо, вот вопрос: зачем нам это нужно? Что не так с большинством людей, работающих сейчас? Почему мы не можем сделать веб-сайт отдельно от API? Какие выгоды мы получаем, если объединим их?
Я объединил их во всех веб-приложениях, с которыми я работал с 2011 года. И самое большое преимущество, которое я испытываю, - это избежание дублирования кода.
Очевидно, что на сервере мы не дублируем контроллеры (в случае MVC). У нас есть один уровень контроллеров, и они управляют как API, так и веб-сайтом (поскольку сейчас это одно дело).
Избежание дублирования кода - очень важное достижение. Более того, я считаю, что это самая важная цель для любого программного проекта.
Эти небольшие веб-приложения работают так, как описано выше: s3auth.com, stateful.co, bibrarian.com. Все они с открытым исходным кодом, и вы можете увидеть их исходный код в GitHub.
Первая проблема не является проблемой. Это просто вопрос вкуса (и уровня образования). Последние две проблемы гораздо серьезнее. Давайте обсудим их.
Трансформация XSL на сервере
Некоторые браузеры не поддерживают XSLT. Как мы решаем это?
Я думаю, что лучший подход - это проанализировать HTTP-заголовок User-Agent в каждом запросе и выяснить, поддерживает ли эта версия браузера XSLT или нет. Это не так сложно сделать, так как эта информация о совместимости является общедоступной.
Если браузер не поддерживает XSLT, мы можем выполнить преобразование на стороне сервера. У нас уже есть XML с данными, сгенерированными сервером, и у нас уже есть подключенный к нему XSL. Все, что нам нужно сделать, это применить последнее к первому и получить HTML-страницу. Затем мы возвращаем HTML-код в браузер.
Кроме того, мы также можем обратить внимание на заголовок Accept. Если он установлен в application / xml или text / xml, мы возвращаем XML, независимо от того, что говорит User-Agent. Это означает, в основном, что с нами обращается некоторый клиент API, а не браузер. И этот клиент не заинтересован в HTML, но в чистых данных в формате XML.
POST вместо PUT
Для этого не существует обходного пути. Браузеры ничего не знают о PUT или DELETE. Таким образом, мы должны также забыть их в наших API-интерфейсах RESTful. Мы должны разработать наш API, используя только два метода: GET и POST. Возможно ли это? Да. Почему нет? Это не будет выглядеть так, как при всех шести методах (некоторые API-интерфейсы также используют OPTIONS и HEAD), но он будет работать.
Что мы получаем?
Хорошо, вот вопрос: зачем нам это нужно? Что не так с большинством людей, работающих сейчас? Почему мы не можем сделать веб-сайт отдельно от API? Какие выгоды мы получаем, если объединим их?
Я объединил их во всех веб-приложениях, с которыми я работал с 2011 года. И самое большое преимущество, которое я испытываю, - это избежание дублирования кода.
Очевидно, что на сервере мы не дублируем контроллеры (в случае MVC). У нас есть один уровень контроллеров, и они управляют как API, так и веб-сайтом (поскольку сейчас это одно дело).
Избежание дублирования кода - очень важное достижение. Более того, я считаю, что это самая важная цель для любого программного проекта.
Эти небольшие веб-приложения работают так, как описано выше: s3auth.com, stateful.co, bibrarian.com. Все они с открытым исходным кодом, и вы можете увидеть их исходный код в GitHub.
Комментариев нет:
Отправить комментарий