producto - Diseño de flujo REST Perl

diagrama de flujo utilidad

Question

Estoy usando Apache y Perl (modperl), con controladores para manejar las solicitudes. Soy nuevo en esto, y no estoy muy seguro de cómo plantear las cosas de una manera sensata.

En este momento tengo lo siguiente:

package MyClass::Handler;
use warnings;
use strict;
# includes
our %action = (
''a'' => /&a,
# And more
);
sub handler {
my $a = shift;
my $r = Apache2::Request->new($a);
# Do things
return Apache2::Const::OK();
}

¿Debo tener un archivo diferente para cada "espacio"? Usando stackoverflow como plantilla, ¿necesito un User.pm para toda la administración de usuarios? Un Story.pm para historias?

Answer 1

Es posible que le interese el excelente marco de CGI :: Application de CPAN. A pesar de su nombre, funciona tanto en CGI normal como en mod_perl. Está diseñado para hacer que la tarea de configurar tablas de despacho de aplicaciones web sea muy simple. Agregue CGI :: Application :: Dispatch y obtendrá buenas URL similares a REST.

Answer 2

Para un proyecto reciente, escribí un controlador de configuración personalizado que implementó una nueva configuración de configuración ResourceURI. Esto me permitió poner las líneas de configuración en httpd.conf así:

ResourceURI SomeResource GET,POST,DELETE "^/...$"

Los tres argumentos son mi nombre de clase de recurso, la lista de métodos HTTP a los que el recurso puede responder y una expresión regular que coincide con los URI (s) para el recurso.

La clase de configuración personalizada reemplaza cada una de estas líneas con un bloque como este:

PerlModule Handler::{resource class}
PerlModule Resource::{resource class}
<Location ~ "{uri regex}">
Order allow,deny
Allow from all
<LimitExcept {allowed methods}>
Order deny,allow
Deny from all
</LimitExcept>
SetHandler modperl
PerlHandler Handler
PerlSetVar Resource {resource class}
</Location>

Esto se encarga de cargar mis clases, deja que Apache rechace los métodos no válidos, establece un indicador para indicar a qué recursos dirigir y pasa todas las solicitudes a través de mi función Handler :: handler ().

package Handler;
sub handler {
my $r = shift;
my $resource_class = ''Resource::'' . $r->dir_config(''Resource'');
my $handler_class = ''Handler::'' . $r->dir_config(''Resource'');
my $resource = $resource_class->new($r, $r->uri);
return Apache2::Const::HTTP_NOT_FOUND unless $resource;
my $method = $r->method();
return Apache2::Const::HTTP_NOT_IMPLEMENTED
unless $handler_class->can($method);
return $handler_class->$method($r, $resource);
}

Ahora solo necesita implementar clases Resource :: * con su lógica de recursos (incluyendo cómo formatear representaciones), y clases Handler :: * con métodos llamados GET, HEAD, POST, etc. y pídales que usen $ r y $ resource para manejar las solicitudes.

Para cada recurso nuevo que necesita, agrega una línea de configuración, implementa una clase de controlador (que he encontrado que a menudo puede ser un módulo casi vacío que hereda de una clase base genérica) e implementa una clase de recursos que contiene la mayor parte del código. También descubrí que a menudo necesito crear un objeto de recurso en el contexto de manejar una solicitud para otro recurso; es por eso que mis constructores de recursos toman un argumento separado para el uri en lugar de solo obtener el uri de $ r. Si estoy en Resource :: Foo y necesito un objeto Resource :: Bar, puedo decir my $ bar = Resource :: Bar-> new ($ r, ''/ bars / 1234''); que crea el objeto Bar usando el mismo URI que usaría un cliente.