J'essaie de mettre en œuvre une API reposante à Perl. Mon idée actuelle est de simplement analyser le chemin_info avec une regex puis envoie la demande au sous-programme approprié qui crachera ensuite le JSON, XML ou même XHTML pour la ressource demandée.
Par exemple pour récupérer des informations sur l'utilisateur 1234 le repos Le client doit le trouver à:
ci-dessous est le code squelette de ma première tentative lors de la mise en œuvre d'une API reposante: Modèle. pl : Avant de procéder plus loin, j'aimerais entendre des pirates de Perl expérimentés si j'ai eu l'idée de base correcte et s'il y a des lacunes sérieuses avec cette approche en termes de performance. Je peux imaginer, après un certain temps, le bloc if / sinon serait vraiment grand. hâte d'entendre votre point de vue pour rendre ce code mieux.
8 Réponses :
Pourquoi n'utilisez-vous pas Apache MOD_REWRITE?
rediriger http://mysite.com/model.pl/users/1234 -> http://mysite.com/users.pl
rediriger http://mysite.com/model.pl/q/5678 -> http://mysite.com/questions.pl
Si vous utilisez Apache et Mod_rewrite, pourquoi même inclure le .pl? Aussi, vous perdez l'identifiant. Vous pouvez réécrire l'URL avec mod_rewrite ou simplement créer un gestionnaire mod_perl et l'utiliser pour gérer / diriger / autre. CGI :: Application :: Dispatch est un gestionnaire mod_perl et peut se reposer.
Je construirais l'application à l'aide de catalyseur et Catalyst :: Contrôleur :: Reste
Merci. Mais je vais passer. Rien contre catalyseur, il s'agit simplement de fournir une interface reposante à une application (très) héritée. Trucs rapides et sales. ;-)
J'utiliserais quelque chose comme CGI :: Application :: Dispatch, il me permet de construire une table d'expédition avec des variables et des méthodes de repos, et vous permet d'utiliser CGI et CGI :: Modules d'application de CPAN. Par exemple: (ou vous pouvez utiliser Auto_REST ou AUTO_REST_LC) Vous pouvez utiliser une classe d'application distincte CGI :: ou simplement des classes dans les classes Vos méthodes de classe contrôleur CGI-APP). CGI :: L'application est également livrée avec des plug-ins pour la sortie XML, JSON ou Texte généré à partir de modèles. CGI-APP (et C :: A :: D) sont des applications CGI et peuvent être utilisées avec (peu ou) aucun changement sous CGI, FastCGI ou MOD_PERL. C :: A :: D est aussi un mod_perl Perlhandler par défaut également.
Pour les API de repos léger, je regarderais mojolicious. Le routage de la demande est vraiment simple et le rendu JSON intégré et l'agent utilisateur gagne du développement de simples API de repos très simples dans mon expérience.
Si votre application va être relativement petite, alors Mojo :: Lite Peut répondre à vos besoins. Par exemple, vous pourrez peut-être faire quelque chose comme ceci:
La solution simple:
use CGI;
my $page = new CGI;
if( $ENV{ 'REQUEST_METHOD' } eq 'GET' ){
my $data = <<json;
{
"isbn" : "123456",
"title" : "Programming Perl",
"author" : "L. Wall"
}
json
print $page->header('application/json');
print $data;
}
Parce que le document ici dans votre exemple ne fonctionne pas en raison de l'espacement, par exemple
la solution simple - avec une modification variable sur $ données code> à l'aide de qq ~~; code> maintient tout code aligné. use CGI;
my $page = new CGI;
if( $ENV{ 'REQUEST_METHOD' } eq 'GET' ){
my $data = qq~
{
"isbn" : "123456",
"title" : "Programming Perl",
"author" : "L. Wall"
}
~;
print $page->header('application/json');
print $data;
}
Je sais que cela a été long depuis longtemps car cette question a été posée, mais j'aimerais fournir des informations mises à jour.
Il y a un module très utile appelé NET :: API :: Reste Utilisation de Apache2 Mod_perl derrière.
Vous devez simplement configurer Apache, et Créez votre propre module héritant depuis NET :: API :: reste et créer un et lorsque quelqu'un accède à l'un de votre point final, votre méthode correspondante est appelée le contexte d'un environnement puissant à utiliser pour répondre à la demande. Vérifiez la page Metacpan Module pour plus d'informations. init méthode dans laquelle vous définissez votre carte des points d'extrémité, tels que:
Puis-je suggérer que si votre objectif est de construire une API reposante que vous dépensez plus de temps à apprendre à vous reposer. Les interfaces reposantes ne sont pas sur l'utilisation de jolies URL pour livrer XML et JSCON.
Vérifiez les autres questions sur Stackoverflow qui expliquent le repos en détail.
S'il vous plaît, ne vous trompez pas, je sais ce qui est repos et je suis au courant des utilisations et des abus de repos. J'ai juste besoin d'une manière rapide et sale de fournir une API reposante pour une application héritée. Il possède une couche de données bien développée, tout ce que je dois faire est de permettre aux gens d'accéder aux données formatées comme JSON ou XML à l'aide de jolis URIS. Je maintiens des choses qui doivent être plus fiables que Sexy. J'ai pris l'intimer de lire les services Web reposants O'Reilly Book et la plupart du livre de Brian avant même de demander. Je pense que c'est une question légitime. En outre, la plupart des discussions parlent de rubis. Merci.
@Darrel Miiler, malheureusement, j'ai juste besoin de faire exactement cela, et plus non plus: utiliser de jolies URL pour livrer XML et JSON. Merci. ;-)
@Geneq, de jolies Uris vont bien, RPC va bien, il suffit de ne pas appeler cela repose quand ce n'est pas le cas, s'il vous plaît. Vous vous trompez également sur la fiabilité - le point de repos consiste à éviter un couplage fragile dans l'espace Uri, il est donc injuste de dire que vous avez besoin de quelque chose de "plus fiable que sexy". Je n'ai pas lu ces livres - si vous êtes intéressé, je vous suggère de lire la thèse de Fielding pour la source faisant autorité.
@Geneq mon erreur. Il est difficile de dire à quel point quelqu'un fait ou ne sait pas du repos. Juste hors de curiosité, pourquoi avez-vous besoin de l'API pour être reposant? Une simple charge de données XML ne serait-elle pas suffisante? Je suppose que vous envisagez de faire connaître le client sur la structure de l'URL à l'avance et sachez que certains infos de XML proviennent de certains points d'extrémité, de sorte quelles avantages une API «reposante» vous fournit?