Existe-t-il des infrastructures Web MVC prenant en charge plusieurs types de demandes?

Question

Dans tous les frameworks MVC que j'ai essayés (Rails, Merb, Waves, Spring et Struts), l'idée de requête (et de réponse) est liée à la notion HTTP de requête. C'est-à-dire que, même s'il existe une AbstractRequest qui est une super-classe de Request, AbstractRequest contient des éléments tels que les en-têtes, la méthode de requête (GET, POST, etc.) et tous les autres éléments liés à HTTP.

Je souhaite gérer un cycle demande-réponse par SMS, Twitter, email ou tout autre support pour lequel je peux créer un adaptateur. Existe-t-il un cadre qui le fasse particulièrement bien?

La seule autre option à laquelle j'ai pensé est de créer, par exemple, un interrogateur Twitter qui s'exécute dans un thread distinct et traduit les messages en requêtes HTTP locales, puis renvoie les réponses.

Si il y avait un bon framework pour plusieurs médias de requête, à quoi ressemblerait le routage? Dans Rails, le routage HTTP ressemble à quelque chose comme:

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

À quoi ressemblerait un itinéraire Twitter ou SMS? Des expressions régulières pour faire correspondre les mots clés et les paramètres?

Answer 1

Vous semblez travailler principalement avec Java et / ou Ruby, alors pardonnez-moi, cette réponse est basée sur Perl: -).

J'aime beaucoup le framework Catalyst MVC ( http://www.catalystframework.org/). Il délègue le mappage réel des demandes (au sens générique général) au code via des moteurs. Certes, toutes les classes de moteur sont actuellement basées sur HTTP, mais j’ai eu l’idée d’essayer d’écrire une classe de moteur qui n’était pas basée sur HTTP (ou qui était peut-être liée à quelque chose comme Twitter, mais séparée des interactions HTTP). que Twitter utilise). À tout le moins, je suis convaincu que cela peut être fait, même si je n'ai pas encore essayé de l'essayer.

Answer 2

Je n'en ai pas vu. Le problème est que la demande est également liée à l'hôte et que la réponse est liée à la demande.

Donc, si vous recevez une demande par courrier électronique et qu'un contrôleur dit de rendre la vue "aboutus", vous aurez besoin du framework MVC pour savoir comment:

• récupérez la demande en premier lieu: le framework MVC aurait presque besoin d'être un hôte (IIS n'est pas averti des nouveaux courriers électroniques, comment le code d'interrogation de votre messagerie est-il renvoyé?)
• autoriser une correspondance de route flexible - la correspondance par chemin / url ne fonctionnerait pas pour tous, un routage de contrôleur spécifique à la demande serait donc nécessaire
• utilisez la vue aboutus email plutôt que la vue SMS ou HTTP nommée "aboutus"
• envoyez la réponse par courrier électronique au bon destinataire

Un framework Web MVC ne va pas le couper - vous aurez besoin d'un "hôte" MVC. qui peut gérer l’activation via le Web, les SMS, les courriels, peu importe.

Answer 3

La spécification Java Servlet a été conçue pour que les servlets soient neutres en termes de protocole et soient étendus d’une manière spécifique au protocole - HttpServlet étant une extension de servlet spécifique au protocole. J'ai toujours imaginé que Sun, ou d'autres fournisseurs tiers d'infrastructure poarty, proposeraient d'autres extensions spécifiques au protocole, telles que FtpServlet ou MailServlet, ou dans ce cas, SmsServlet et TwitterServlet.

Au lieu de cela, les utilisateurs ont complètement contourné la structure Servlet ou ont construit leurs protocoles sur HTTP.

Bien sûr, si vous souhaitez implémenter une extension spécifique à un protocole pour vos protocoles requis, vous devez développer la pile entière - objet de requête, objet de réponse, mécanisme d'identification des sessions (par exemple, en utilisant MSISDN dans un SMS). au lieu de cookies), un framework de templates et de rendu (équivalent de JSP) - puis créez un framework MVC par dessus.

Answer 4

Vous pouvez implémenter un adaptateur REST sur votre site Web, qui remplace les modèles et redirections en fonction des paramètres d'entrée.

Toutes les demandes arrivant sur api .votrehost.com seront traitées par l'adaptateur basé sur REST.

Cet adaptateur permettrait d'appeler votre site Web par programmation et d'obtenir le résultat dans un format analysable.

En pratique, cela signifie: cela remplace les modèles par un moteur de modèle propre, sur lequel cela se produit:

• au lieu du modèle attribué, un modèle générique xml / json est appelé. Il génère simplement un fichier xml contenant tous les modèles de modèle

alors vous pouvez rendre votre Twitter Poller, SMS Gateway ou même l'appeler depuis Javascript.