.
почерпнуть какие-нибудь интересные специализации, не упоминаемые в 1001 копирайтерской статье
Подскажите, есть ли какие-то авторитетные источники про проектирование архитектуры веб-приложений на реактивных фреймворках, в частности - Vue. Может быть есть книжки, статьи, доклады или просто дневники экспертов? Я ничего прямо толкового не нашёл.
Как выводить шаблон в mvc?
echo "*тут весь текст шаблона*";,
Никаких особых правил нет, если мы говорим просто о протоколе RPC, а не о какой-нибудь более подробной спецификации как, например, JSON-RPC. Просто так следовать этим спецификациям смысла нет. Главное требование к АПИ - чтобы им было удобно пользоваться тем, кто им собирается пользоваться.
REST - это изначально набор архитектурных ограничений для клиент-серверных приложений. Там 6 обязательных и 7-ое необязательное. Наиболее подробно описана архитектура в диссертации, в которой и был введён этот термин - https://www.ics.uci.edu/~fielding/pubs/dissertatio...
REST предполагает довольно жесткие ограничения для обеспечения некоторых принципов описанных в диссертации. Один из них - scalability.
В народе есть довольно странная мода, называть "API" только взаимодействие через RPC. То, как работает браузер с серверами сайтов - тоже API. Это сейчас мы используя JS можем расширять возможности браузеров до огромных масштабов, и делать из них RPC клиентов.
REST предполагает что клиент ничего не знает о сервере кроме одной точки входа(ограничение "Starting with null style из диссертации"), и не знает куда слать запросы, REST клиент лишь умеет отображать какой-то стандартный заранее обговоренный набор форматов, как браузеры умеют отображать (ограничение "Uniform interface", хотя его понять сильно сложнее) html, jpg и т.п.
Так вот, то как работал Веб до того как из браузеров стали с помощью JS делать полноценные приложения и можно назвать примерами взаимодействия по REST API, в описании ограничения "Uniform interface" есть подпункт HATEOAS (Hypertext as the engine of application state). Суть в том что переходы состояния клиента полностью контроллируются со стороны сервера, и в примере с Web`ом всё довольно просто - переходы состояния клиента контроллируются через теги
<a>и<form>. Вобщем, количество сайтов в интернете росло и растет стремительно, а никаких изменений в наш клиент(браузер), чтобы они работали вносить нет необходимости, миллионы сайтов мы посещаем используя один и тот же клиент, потому что у них единый "Uniform interface".Вобщем, сумбурно описал, я хотел лишь сказать что нет смысла пытаться соблюдать какие-то ограничения только за то что они есть в REST, если для вашего приложения нет потребности в этих ограничениях. SPA приложения, или там, АПИ для мобилки это по сути всегда RPC, нет нужды пытаться назвать его по другому. Создавать свой REST клиент(по сути новый браузер) это долго, дорого, и для обычного приложения никогда не окупится )
Да самый простой веб сайтик без JS-а)
Там будет и "Starting with null style", и "Client-server", и "Caching", и "Uniform interface". Единственное что, проблемы со stateless из-за сессий, и есть ли там " Layered System" мы на клиенте не узнаем )
P.S. И да, не смотря на то что "REST ignores the details of component
implementation and protocol syntax in order to focus on the roles of components", не удивительно что он так удобно ложитьсяна HTTP, автор термина REST (Рой Филдинг), в том числе и со-автор спецификации HTTP )