“Una interfaz de programación de aplicaciones o API (del inglés Application Programming Interface) es el conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción”.
- Wikipedia. La enciclopedia libre
Según esta definición, como la entendía antes de descubrir las APIs Web, me preguntaba lo siguiente: ¿Dónde están las funciones y los procedimientos cuando armo un listado de vídeos de YouTube?, ¿dónde están estas funciones cuando obtengo un Google Maps?
Roy Thomas Fielding y REST
Roy Thomas Fielding es uno de los principales autores de la especificación HTTP (RFC 2616) y obtuvo su doctorado hace nueve años, en 2000, en la Universidad de California, con su tesis Estilos Arquitecturales y el Diseño de Arquitecturas Software basadas en Red. En este trabajo, Fielding presenta la Transferencia de Estado Representacional, o REST (Representational State Transfer).
Para qué sirve REST
Actualmente, el término REST hace referencia a un enfoque para desarrollar y proporcionar servicios web y es una alternativa a los servicios web SOAP. No tengo ninguna experiencia en SOAP y hablaré poco de él para no meter mucho la pata.
Por lo que creo haber entendido, hay muchas diferencias en el funcionamiento de estas dos tecnologías. Por ejemplo, con SOAP, que se basa en RPC, tenemos un conjunto de métodos que hacen algo, mientras que en REST los que hacen algo son los recursos, identificados por un URL.
Qué es un servicio web
Según el W3C: “Un conjunto de aplicaciones o tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web“.
Cómo funcionan las APIs basadas en REST
Bueno, pues las funciones o métodos que yo buscaba ¡son los URL! Si en RPC teníamos métodos como getUser(), addUser() o removeUser(), ahora, en REST, tenemos recursos identificados con URLs. Como explica muy bien la Wikipedia: “Los clientes trabajan con estos recursos a través de las operaciones estándar de HTTP, como GET para descargar una copia del recurso“.
Más concretamente, esto es lo que se hace aquí, por ejemplo, cuando le pedimos al geocodificador de Google que nos mande un mapa. Esto es lo que hicimos, también, aquí, cuando le pedimos a YouTube que nos mandara un listado con los vídeos más vistos. En ambos casos, la respuesta que recibimos de este recurso es un XML, aunque esto se puede parametrizar en el URL de consulta para que sea, por ejemplo, otra, como JSON.
¿Entonces, qué es el API de YouTube?
No hace mucho, algunas compañías comenzaron a liberar sus APIs: Amazon, Yahoo!, Google, etc. En otras palabras, expusieron sus servicios web en forma de recursos REST, a través de un URL, para que los consumidores de estos servicios (los programadores) pudieran acceder a este procesamiento a través del protocolo HTTP. El API de YouTube es, pues, un servicio web basado en REST.
Dónde está REST
¿Recuerdas que estos días descubrimos el funcionamiento de los blogs y de los feeds RSS, gracias al videotutorial RSS hablando en plata? ¡Pues resulta que la tecnología que hay detrás de ellos es REST! Ciertamente, los lectores de feeds consultan un URL, el del feed, que devuelve un XML.
Hasta otra
Espero que este post te haya gustado y lo encuentres útil. Ya conocemos un poco mejor qué es esto que andamos tocando (¡APIs REST!) y cómo utilizarlas, que es de lo que se trata; si encuentras algún fallo, ¡deja aquí algún comentario!
Más información de todo este asunto aquí…
http://es.wikipedia.org/wiki/Representational_State_Transfer
http://www.ibm.com/developerworks/xml/library/x-youtubeapi/
http://phpwebservices.blogspot.com/2008/01/rest-with-php_20.html
www.di.uniovi.es/~cueva/asignaturas/doctorado/2006/trabajos/Ponencia%20REST.pdf
http://es.wikipedia.org/wiki/Roy_Fielding
http://www.sematopia.com/?p=153
A mí me ha ido muy bien leer lo que dice uno y compararlo en el otro. Hueniverse explica, a través de los programas de ejemplo faji y beppa, cómo ve el usuario el proceso OAuth (personalmente me ha gustado mucho y lo encuentro muy práctico y sencillo). Por otra parte, el enlace de La guía del desarrollador de Google es bastante más técnico y presenta, en 14 pasos, el diagrama de flujo del proceso OAuth. En un contexto CakePHP y YouTube, mi resumen sería este: