Сообщение от B~Vladi
|
|
Они и не должен его иметь, это же роутер, он только проксирует запрос на конкретный сервис, в зависимости от URL. Этим будет заниматся сервис...
|
Вот поэтому и предлагаю вам более гибкую систему - добавить в роутер логику по разбору URL, и формированию дерева ответа. Он уже не будет называться роутером, но не суть.
|
Сообщение от B~Vladi
|
|
Такого в принципе быть не может, или ты что-то другое имел ввиду?
|
Если делаете исключительно веб-API, то да, не может. Но ведь в исходном посте вопрос был о полноценном веб-приложении, умеющем как отвечать на API запросы, так и формировать HTML-страницы.
Обычно для формирования одной страницы сайта вам придется обратиться к нескольким своим сервисам (блочный дизайн, так?), отсюда и вызов нескольких сервисов на один HTTP-запрос. И отсюда же - необходимость логики для формирования всей страницы из кирпичиков независимых сервисов:
Пришло:
http://domain.com/forum/page=3
Вызвали свои сервисы:
- getMenu;
- getUserData;
- getPosts;
- getAd;
- get...
Положили все это в дерево ответа. Отдали шаблонизатору, отрендерили, вернули результат в виде HTML страницы.
Пришло:
http://domain.com/api?getAd=8
Вызвали:
- getAd;
Положили в дерево, отрендерили в JSON, вернули.
В примере выше "getAd" - ваш сервис, он независим от остального и всегда выдаёт одинаковую модель, хотя и вызывается из совершенно различных контекстов. А фронт-контроллер определяет, какой набор сервисов вызвать согласно запрошенному URL, и в каком шаблоне отрендерить результат.
Для простоты понимания я бы предложил ввести еще один термин - Flow (Поток). Тогда верны утверждения:
- URL определяет, какой Flow будет отработан;
- Flow содержит нужный набор сервисов;
- Фронт-контроллер выполняет Flow, вызывая нужные сервисы и сохраняя ответы в результирующую модель;
- Фронт-контроллер определяет, корректно ли выполнен Flow, и принимает решение о выборе шаблона;
- Шаблонизатор рендерит модель в указанный контроллером шаблон.