The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Посмотрите на 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 и один и тот же механизм серверной обработки для обоих случаев? Что, если переместить всю задачу рендеринга на клиентскую сторону (браузер) и позволить серверу работать исключительно с данными?
XSLT - это технология, которая может нам в этом помочь. В статье “XML+XSLT в браузере” я кратко объяснил, как это работает в браузере. В двух словах, сервер возвращает XML с некоторыми данными и ссылкой на XSL-стиль. Стиль, выполняемый в браузере, преобразует XML в HTML. Язык XSL так же мощен, как и любой другой механизм рендеринга, например JSP, JSF, Tiles и т.д. Фактически, он гораздо более мощный.
Используя такой подход, мы буквально удаляем всю слой рендеринга (“Представление” в парадигме MVC) с сервера и перемещаем его в браузер.
Если мы сможем это реализовать, веб-сервер будет предоставлять только RESTful API, а каждая ответная страница будет иметь прикрепленную XSL-стиль. Что мы получим? Мы обсудим это позже, в конце статьи. А сейчас давайте посмотрим, с какими проблемами мы столкнемся:
XSLT 2.0 не поддерживается всеми браузерами. Даже XSLT 1.0 поддерживается только некоторыми из них. Например, Internet Explorer 8 вообще не поддерживает XSLT.
Браузеры поддерживают только методы HTTP
GETиPOST, в то время как традиционные RESTful API также используют, по крайней мере, методыPUTиDELETE.
Первая проблема на самом деле не является проблемой. Это всего лишь вопрос вкуса (и уровня образования). Последние две проблемы намного серьезнее. Давайте обсудим их.
XSLT не поддерживается некоторыми браузерами. Как мы можем это решить?
Я считаю, что лучший подход - разбирать заголовок HTTP User-Agent в каждом запросе и делать предположение, поддерживает ли данная версия браузера XSLT или нет. Это не так сложно сделать, так как эта информация о совместимости является общедоступной.
Если браузер не поддерживает XSLT, мы можем выполнить преобразование на стороне сервера. У нас уже есть XML с данными, сгенерированными сервером, и уже прикреплено XSL. Все, что нам нужно сделать, это применить последний к первому и получить HTML-страницу. Затем мы возвращаем HTML в браузер.
Кроме того, мы также можем обратить внимание на заголовок Accept. Если он установлен на application/xml или text/xml, мы возвращаем XML, независимо от того, что говорит User-Agent. Это означает, в основном, что к нам обращается какой-то клиент API, а не браузер. И этот клиент не заинтересован в HTML, а в чистых данных в формате XML.
Нет обходных путей для этого. Браузеры ничего не знают о PUT или DELETE. Поэтому мы также должны забыть о них в наших RESTful API. Мы должны разработать наш API, используя только два метода: GET и POST. Это вообще возможно? Да. Почему бы и нет? Это не будет выглядеть так красиво, как с шестью методами (некоторые API также используют OPTIONS и HEAD), но это будет работать.
Хорошо, вот вопрос: зачем нам это нужно? Что не так с тем, как работает большинство людей сейчас? Почему мы не можем создать веб-сайт отдельно от API? Какие преимущества мы получаем, объединив их?
Я объединяю их во всех веб-приложениях, с которыми работал с 2011 года. И самое большое преимущество, которое я получаю, - это избегание дублирования кода.
Очевидно, что на сервере мы не дублируем контроллеры (в случае с MVC). У нас есть один слой контроллеров, и они управляют как API, так и веб-сайтом (поскольку они теперь являются одним целым).
Избегание дублирования кода - очень важное достижение. Более того, я считаю, что это самая важная цель для любого программного проекта.
Эти небольшие веб-приложения работают точно так, как объяснено выше: s3auth.com, stateful.co, bibrarian.com. Они все открытые исходные коды, и вы можете увидеть их на GitHub.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 16:00
