alexbm8_apuntes_01-06-09

Apuntes de la penúltima clase (1 de Junio)
alexbm8 hizo el resumen de la clase anterior, y comentamos los últimos detalles sobre las prácticas.

Vallesquino nos comentó su ejercicio de autoevaluación T3.1, describiendo la utilidad de los servicios web. Las aplicaciones futuras está orientadas a las aplicaciones basadas en el navegador del cliente, como las aplicaciones online de Google.

DELETE se usa para eliminar un URL.
 * Continuamos con el temario: HTTP**. La mayoría de las aplicaciones realizan sus funciones sobre HTTP, aunque la mayoría de los servidores están diseñados para resolver peticiones tales como GET (obtener la página), POST (envío de formularios), HEAD (obtiene la cabecera de una web para saber si el recurso ha sido modificado, más ligero que GET). También está PUT, similar a GET, sólo que cambia o crea recursos. Cuando hacemos PUT, el servidor crea un recurso con una URL determinada, por lo que tiene problemas con la seguridad, y sólo se usa para usuarios autenticados.

Estos comandos se dividen en seguros (dejan al servidor en el mismo estado en que se encontraba antes de ejecutarlo: HEAD y GET). La otra clasificación serían los idempotentes. POST no estaría en ninguno de los dos grupos.

El código de respuesta de los servidores web está estandarizado. 200 significa "petición correcta, ahí está el resultado". También existen códigos 201, 202, etc. 300 es redirección, 400 son errores del cliente y 500 son errores en el servidor El error 503 suele estar asociado a un exceso del ancho de banda contratado por parte del servidor.

Cuando se programa una aplicación es importante conocer el código que debemos esperar.

Las aplicaciones construidas alrededor de HTTP se suelen denominar RESTful. Para mandar información estructurada del cliente al servidor (y no se pueda usar la URL) se usa un estándar denominado POX, que básicamente es XML bien formado.

Básicamente cualquier lenguaje que pueda construir cadenas puede trabajar con la filosofía REST, y por tanto son muy independientes del lenguaje.

Vemos un ejemplo con la API de Twitter. Accedemos al usuario aap_ugr (password: ugr_aap).[fichero twitter.pl]. Si hacemos muchas peticiones, puede que nos devuelva el estado 503. code format="perl"
 * 1) !/usr/bin/perl

use LWP::UserAgent;# hace pasar el programa por el navegador use HTTP::Request::Common qw(POST GET);

my $status = shift; # aquí se indicaría el estado my $ua = LWP::UserAgent->new; # agente de usuario my $req = POST 'http://aap_ugr:xxx@twitter.com/statuses/update.xml', #comando REST, llamamos a la función statuses [ status => $status ]; my $res = $ua->request($req);# trasladamos la petición al agente de usuario print "Resultado:\n",$res->content,"\n";

code

Para ejecutarlo hacemos "perl [nombre _fichero] [mensaje]" Vimos una versión mejorada: twitter2.pl code format="perl"
 * 1) !/usr/bin/perl

use LWP::UserAgent; use HTTP::Request::Common qw(POST GET); use XML::Simple;

my $status = shift; my $ua = LWP::UserAgent->new; my $req = POST 'http://aap_ugr:xxx@twitter.com/statuses/update.xml', [ status => $status ]; my $res = $ua->request($req); if ($res->is_success) { # Analiza el XML de respuesta para ver si la petición ha tenido éxito. my $respuesta=XMLin($res->content); print "El mensaje ", $respuesta->{'text'}, " ha recibido el ID ", $respuesta->{'id'}, "\n"; } else { die $res->status_line; }

code

No siempre es necesario ingresar el usuario y la clave, sólo para aquellas funciones que necesiten autenticación. La API de twitter presenta una gran variedad de funciones

Tuenti aún no dispone de API para el desarrollo de aplicaciones REST, pero probablemente pronto disponga de uno.

Para terminar vimos algo de XML-RPC, un protocolo para acceder fácilmente a recursos. Es un protocolo anterior a SOAP, y es bastante ligero y fácil de utilizar. Otra de las ventajas de XML-RPC es que es capaz de representar estructuras de datos complejas como arrays. Dispone de garn variedad de librerías para trabajar con él en múltiples lenguajes como ruby, perl, etc. Vimos el ejemplo en ruby de cómo enviar a un blog una entrada a través de los ficheros blog.rb e historia.xml: code format="ruby"
 * 1) !/usr/bin/ruby

require 'rexml/document' require 'xmlrpc/client' require 'pp'

include REXML documento = ARGV[0] file = File.new(documento) doc = Document.new(file) titulo = doc.root.elements['titulo'][0].to_s contenido = doc.root.elements['contenido'][0].to_s

print titulo print contenido server = XMLRPC::Client.new2("http://aapugr.wordpress.com/xmlrpc.php" ); fecha = Time.new.to_a pp fecha pp fecha.to_a item = { 'title' => titulo, 'description' => contenido, 'pubDate' => Time.gm(fecha[5],fecha[4],fecha[3],fecha[2],fecha[1],fecha[0],0), 'publish' => true } print "Enviando: " pp item; result = server.call("metaWeblog.newPost", 1,'aapugr', '448e83', item) pp result
 * 1) Enviar
 * 1) accedemos a la función, id de bitácora, usuario, contraseña y objeto.

code

code format="xml"  Qué tiempo nos espera... Bienvenidos al maravilloso mundo de los exámenes de Junio!! code