Mucho se habla hoy en día sobre arquitectura orientada a servicios es decir, tener un servicio que de alguna manera encapsula una lógica con sus problemáticas correspondientes y proporciona un resultado que responde a la invocación de ese servicio.
Por lo general, la información que se muestra en una página es resultado de un proceso, como por ejemplo una búsqueda de datos en la base de datos. Cuando queremos mostrar una noticia, enviamos por parámetro GET a una página el Id de la noticia, al momento en que la página recibe ese dato, lo obtiene y realiza una búsqueda de datos obteniendo un ResultSet que luego es procesado por nosotros y el resultado final es mostrado en la página en un formato que por lo general será decidido por el diseño del sitio.
Hemos hablado de dos partes bien marcadas en el ejemplo anterior:
- Desde que recibimos el Id como parámetro, se ejecuta un proceso que correspondería, en una arquitectura MVC, a la “C” o Controller, que procesa dicha información también llamados Actions y luego cuando ya tenemos los datos finales,
-
la presentación correspondería a la “V”, es decir la Vista. Estos son conceptos que fácilmente son entendidos por cualquier desarrollador que haya usado algún framework MVC como por ejemplo Symfony.
Resumiendo, siempre que pensamos en una página estamos pensando automáticamente en dos partes, el controlador y la vista, la acción que se procesará al recibir la petición y la presentación de dichos datos obtenidos, y como mucho tiempo nos hemos acostumbrado generalmente para crear una página programamos estos dos elementos como si no pudieran separarse.
Hagamos un ejemplo teórico e imaginemos un sitio que debe mostrar cierta información, pero, al ser accedido desde un dispositivo móvil debe presentar los datos con un formato adaptado a estos dispositivos (como por ejemplo usando jQuery Mobile), a diferencia de cuando lo accedemos desde una PC en donde se debería mostrar en formato estándar.
Si nuestro controller está unido a nuestro diseño y presentación de la información estamos hablando de tener que duplicar la programación de la lógica que escribimos en nuestro controller cuando por lo general los cambios se manejarán más bien a nivel de visualización, es decir la plantilla, el diseño, estilos, etc., pero los datos siguen siendo los mismos.
La propuesta es crear la lógica de procesamiento de información como si se tratara de un sitio diferente y una vez procesada nos lo pueda entregar en un formato estándar para que podamos decidir como queremos que se presente. Por lo general se utiliza para el retorno de la información textos XML o JSON. Las páginas o programas que necesiten de esa información procesada, invocarán a ese recurso (dirección URL) y obtendrán lo necesario (datos en formato XML/JSON) para mostrarlo como más convenga.
REST se maneja utilizando los métodos de HTTP para realizar los requests a la información y retornar como cabeceras del response codigos HTTP en conjunto con la información requerida. Entremos un poco más en detalle sobre esto.
Comprendiendo los métodos HTTP para realizar el REQUEST
Por lo general, como ya hemos visto en el artículo de GET vs POST, la gran mayoría de los programadores web comienzan entendiendo de forma “incompleta” el significado de los métodos HTTP y la gran mayoría solo conocen estos dos cuando en realidad existen otros para especificar el objetivo del request que estamos invocando.
Para esto conozcamos los 4 métodos de petición HTTP que utilizaremos:
- GET: Este método significa que quiero obtener información del servidor, ya se directamente ingresando a un URL SIN enviar parámetros como por ejemplo sería obtener el listado de los comentarios de este blog, así como también enviando un Id específico para que sea mostrado UN comentario.
-
POST: Nos servirá cuando por ejemplo queremos crear un comentario enviando por POST los parámetros de un formulario.
-
PUT: Nos permitirá modificar por ejemplo un comentario de este blog y es una práctica muy común hoy en día que cuando ingresamos a un formulario de actualización enviamos los datos del formulario y en el action de nuestro form ponemos una URL como “comentarios.php?id=1″ en donde también estamos enviando parámetros por medio de la URL. Esto es lógico ya que para actualizar un registro debemos enviarle el identificador del registro a modificar.
-
DELETE: Nos permitirá enviar un parámetro por la URL para borrar un registro en el servidor.
Utilizando y desglosando estos cuatro conceptos, tenemos la posibilidad de indicar explícitimente al servidor que acción queremos ejecutar a través del request proporcionando de esta manera el objetivo.
Comprendiendo los códigos HTTP para devolver un RESPOSE
Más de uno ya sabrá de memoria el significado del código 404. Cuando intentamos ingresar a una página no existente, el código devuelto por el servidor es éste, permitiendo especificar como un identificador del tipo de respuesta obtenido. El código opuesto a no encontrar la página por lo general sería el 200 que indica que la petición se ha ejecutado exitosamente.
Como podemos ver en la imagen anterior al ingresar a una página no existente se muestra un mensaje “Lo sentimos, pero estás buscando algo que no está aquí”. Este mensaje se puede mostrar gracias a que como se puede ver en el FireBug, nos fue retornado un mensaje 404 – Not Found de la página noexiste.html por lo que al obtener ese código nos es fácil saber que el recurso no fue encontrado.
Por el contrario, podemos ver que sí se puedo encontrar y descargar el archivo ga.js correspondiente a Google Analytics retornando entonces un código 200 – OK.
Como podemos ver en Wikipedia los mensajes de respuesta están clasificados por números:
- 100: Peticiones informativas
- 200: Peticiones correctas
- 300: Redirecciones
- 400: Errores del cliente
- 500: Errores del servidor
Aplicando la teoría con un ejemplo
Para aplicar un poco esta teoría he creado un repositorio en Github en donde se encuentra levantado un proyecto creado con Silex un micro-framework PHP (hermano menor de Symfony2) que nos permite fácilmente tener un proyecto base para probar la funcionalidad de un servidor REST.
Cabe mencionar que este proyecto solo provee información y no es para mostrarla como una página ya que eso lo haremos más adelante al crear un cliente de servicios REST.
El ejemplo consiste en usar una tabla para ejecutar un CRUD básico. La idea es mantener este proyecto a fin de que cuando necesitemos tener un esqueleto de servidor REST podamos simplemente descargarlo y tenerlo como un proyecto base utilizando Silex que como bien mencionamos es un micro-framework, es decir para “proyectos pequeños” donde necesitemos “desarrollo rápido”.
En el siguiente capítulo iremos viendo paso por paso las partes de nuestro proyecto y explicando los conceptos básicos de Silex.
Descubre más desde Neurosimbiosis
Suscríbete y recibe las últimas entradas en tu correo electrónico.