Существуют ли какие-либо веб-фреймворки MVC, которые поддерживают несколько типов запросов?

Question

В каждой MVC-структуре, которую я пробовал (Rails, Merb, Waves, Spring и Struts), идея запроса (и ответа) связана с HTTP-понятием запроса. То есть, даже если существует AbstractRequest, который является суперклассом Request, в AbstractRequest есть такие вещи, как заголовки, метод запроса (GET, POST и т. Д.) И все остальные вещи, связанные с HTTP.

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

Единственная другая опция, о которой я подумал, - это, например, создание опроса Twitter, который запускается в отдельном потоке и преобразует сообщения в локальные HTTP-запросы, а затем отправляет ответы обратно.

Если бы было хорошей платформой для мультимедийных запросов, как бы выглядела маршрутизация? В Rails HTTP-маршрутизация выглядит примерно так:

map.connect 'some/path/with/:parameter_1/:paramter_2', :controller => 'foo', :action => 'bar'

Как будет выглядеть маршрут через Twitter или SMS? Регулярные выражения для соответствия ключевым словам и параметрам?

Answer 1

Спецификация Java Servlet была разработана для того, чтобы сервлеты были нейтральными по отношению к протоколу и были расширены с учетом протокола - HttpServlet был расширением для конкретного протокола Servlet. Я всегда думал, что Sun или другие третьи поставщики инфраструктуры poarty предложат другие специфичные для протокола расширения, такие как FtpServlet или MailServlet, или в этом случае SmsServlet и TwitterServlet.

Вместо этого произошло то, что люди либо полностью обошли инфраструктуру сервлетов, либо построили свои протоколы поверх HTTP.

Конечно, если вы хотите реализовать специфичное для протокола расширение для требуемых протоколов, вам необходимо разработать весь стек - объект запроса, объект ответа, механизм идентификации сеансов (например, с использованием MSISDN в SMS-сообщении). вместо файлов cookie) - шаблонизатор и среду визуализации (эквивалент JSP), а затем на ее основе создайте инфраструктуру MVC.

Answer 2

Я не видел ни одного. Проблема заключается в том, что запрос также связан с хостом, а ответ связан с запросом.

Так что, если вы получите запрос по электронной почте, и контроллер скажет, что нужно сделать представление "aboutus", вам понадобится среда MVC, чтобы знать, как:

• Получите запрос в первую очередь - инфраструктура MVC почти должна быть хостом (IIS не получает уведомления о новых электронных письмах, так как ваш код опроса электронной почты срабатывает?)
• разрешить гибкое сопоставление маршрутов - сопоставление по пути / URL не будет работать для всех, поэтому потребуется маршрутизация для конкретного запроса
• используйте представление aboutus email вместо представления SMS или HTTP с именем aboutus
• отправить ответ по электронной почте правильному получателю

Веб-инфраструктура MVC не собирается ее сокращать - вам понадобится MVC-хост, который может обрабатывать активацию через Интернет, SMS, электронную почту и т. Д.

Answer 3

Вы можете внедрить Адаптер на основе REST для своего веб-сайта, который заменяет шаблоны и перенаправляет в соответствии с входными параметрами.

Все запросы, поступающие на api .yourhost.com, будут обрабатываться адаптером на основе REST.

Этот адаптер позволит программно вызывать ваш веб-сайт и получать результат в разобранном формате.

Практически это означает: он заменяет шаблоны собственным механизмом шаблонов, на котором это происходит:

• вместо назначенного шаблона вызывается общий шаблон xml / json, который просто выводит xml, содержащий все переменные шаблона

тогда вы можете сделать свой Twitter Poller, SMS Gateway или даже позвонить ему из Javascript.

Answer 4

Похоже, вы работаете в основном с Java и / или Ruby, так что простите, что этот ответ основан на Perl: -).

Мне очень нравится Catalyst MVC Framework (http://www.catalystframework.org/).). Он делегирует фактическое сопоставление запросов (в общем, общем смысле) к коду через движки. Конечно, все классы движков в настоящее время основаны на HTTP, но у меня возникла идея попытаться написать класс движка, который не был бы основан на HTTP (или, возможно, был привязан к чему-то вроде Twitter, но был отделен от HTTP-взаимодействий, которые использует Twitter). По крайней мере, Я убежден, что это можно сделать, даже если я еще не удосужился попробовать.