2011-12-30 10 views
10

Como tengo entendido (desde la perspectiva del cliente HTTP) tenemos LWP y libcurl (WWW :: Curl) disponibles en Perl. ¿Tenemos algún criterio que elegir?¿Debo usar Perl's LWP o lib curl?

+2

Sí. libcurl es el camino a seguir.Gran software de un chico que se preocupa por la calidad del software; y un gran soporte de una lista de correo activa de usuario/desarrollador. –

+2

También hay LWP :: Curl :). –

Respuesta

21

Sólo hablando desde el punto de vista de la API, prefiero LWP. El problema con Curl es que obviamente está hecho de una biblioteca C. Por ejemplo:

$curl->setopt(CURLOPT_URL, 'http://example.com'); 
my $response_body; 
$curl->setopt(CURLOPT_WRITEDATA, \$response_body); 

my $retcode = $curl->perform; 
if ($retcode == 0) { 
    # Response is now in $response_body 
} 
else { 
    die "Error\n"; 
} 

Configuración de parámetros con setopt()? ¿Devolviendo la respuesta usando una referencia a uno de esos parámetros? ¿Tener un método devuelve 0 en caso de éxito? Estas cosas son idiomáticas en el código C, pero no en el OO Perl moderno.

Aquí es más o menos el mismo código en LWP:

my $response = $lwp->get('http://example.com'); 
if($response->is_success) { 
    $response_body = $response->decoded_content; 
} 
else { 
    die "Error\n"; 
} 

La llamada a is_success() es más auto-documentado y se mezcla mejor dentro de un lenguaje orientado a objetos. Los codificadores C se acostumbraron a ver el código como if($retcode == 0) en caso de éxito por razones históricas, pero no hay ninguna razón para que los programadores de Perl deban recuperar este hábito. Lo anterior también muestra cómo LWP se ocupa fácilmente de la decodificación de contenido para nosotros, lo que Curl deja para que usted haga.

No se muestra arriba, pero Curl también te obliga a manejar el análisis de parámetros GET/POST por tu cuenta. En LWP, pasas un hash y rompe los pares name=value para ti. Cookies, también. Curl es de muy bajo nivel de esa manera.

Curl puede ser más rápido, pero pregúntese cuánto importará en su aplicación. ¿De verdad vas a enviar 100 solicitudes en un corto período de tiempo? Si es así, entonces Curl puede valer la pena. Si no, entonces ve por la facilidad de implementación, que creo que LWP va a ganar sin mucha lucha.

10

LWP es el más utilizado, y funciona con los módulos estándar de facto como HTTP :: Request, HTTP :: Headers, HTTP :: Cookies, etc. WWW :: Curl es a veces más potente y, a veces más rápido, pero tiene el tipo de interfaz extraña que hace descaradamente obvio que está envolviendo una biblioteca C. Usaría LWP a menos que haya alguna razón para no hacerlo.

4

Todo depende de sus requisitos y expectativas. Creo que libcurl y LWP tienen conjuntos de características ligeramente diferentes y funcionan ligeramente diferente.

Consulte este libcurl vs LWP performance tests o this. Le insto a que ejecute su propia comparación para sus propias características y entornos para que sea realmente relevante.

(exención de responsabilidad: yo soy el autor principal del libcurl)

+1

Gracias por libcurl :) –

5

Me gusta usar Mojo::UserAgent ahora. Yo incluso wrote about it for the 2011 Perl Advent Calendar.

Sin embargo, en realidad no hay una respuesta a su pregunta general. Utiliza la herramienta correcta para su trabajo. Sin saber lo que intenta hacer, es prácticamente imposible guiarlo. Aprenda ambos y luego elija el que le facilita la tarea. Uno podría tener mejores perillas y diales para lo que necesita hacer.

1

Preferiría LWP porque es un módulo de núcleo perl. Para interactuar con servicios web, el curl de la herramienta de línea de comandos tiene algunas características útiles, como la opción anyauth, y también puede emitir fácilmente las solicitudes HTTP PUT y HTTP DELETE. Creo que PUT y DELETE fueron added as convenience methods to LWP just recently in 2011, corríjanme si me equivoco.