Arquitectura del Framework

Tal y como fue mencionado en las referencias de REST proporcionadas en la sección anterior, el concepto de HTTP URLs es central al estilo arquitectónico REST. Además, REST organiza su sus unidades de procesamiento como recursos, y cada recurso está mapeado a un URL en particular. Ya que los URLs son globales - cada organización mantiene el conjunto de URLs que cae bajo su dominio - esto proporciona a REST de un esquema de direccionamiento global. Esta consideración aparentemente trivial en realidad simplifica muchas de las complejidades que se encuentran en un escenario típico de web services.

NOTA: Esta sección ha sido extraida del tutorial. Para las explicaciones completas favor de referirse a dicho documento.

Ya que la arquitectura REST está principalmente basada en jerarquías de URLs, es importante saber que partes de un URL mapean a qué partes del API de java servlets. Los siguientes URLs representan diferentes recursos en una jerarquía REST:

• http://example.com/forum/topics representa los tópicos en una aplicación de foro.
• http://example.com/forum/topics/234 representa un tópico en particular en una aplicación de foro.
• http://example.com/forum/topics/234/comments representa los comentarios de un tópico ( en la misma aplicación de foro ).
• http://example.com/forum/topics/234/comments/34 representa un comentario particular en un tópico particular.

Desde una perspectiva de implementación en el API de java servlets, partes de los URLs anteriores serán mapeados a recursos de acuerdo a la siguiente imagen ( al menos en una implementación Cetia4 ).

Esto significa que en Cetia4 REST Framework, todas las peticiones que inician en un nivel dado serán atendidas por un único servlet, aunque desde una perspectiva REST estos URLs diferentes representan recursos diferentes. Además, cada uno de estos URLs puede ser accesado utilizando diferentes métodos HTTP: GET, POST, PUT, DELETE; y utilizando en cada caso diferentes query strings y parámetros lo que puede conducir a comportamientos distintos. Una buena parte del tutorial se enfoca explicítamente a como el framework se las arregla para hacer estas asociaciones de una forma sencilla y conveniente; y se explican en dicho documento desde los casos más sencillos hasta los más elaborados.

Los servlest de Cetia4 son subclases de com.acsinet_solutions.cetia4.controller.rest.RestServlet, que a su vez se deriva de javax.servlet.http.HttpServlet.

RestServlet es una clase abstracta que implementa los métodos doGet(), doPost(), doPut() y doDelete() methods, y habilita las facilidades del framework.

Cetia4 REST Framework utiliza un enfoque similar al de la espeficación Java Portlets para atender peticiones. En este modelo, las peticiones se dividen en dos tipos: las peticiones tipo render ( desplegado ) y las peticiones tipo action ( acción ). En Cetia4, las peticiones render responden peticiones HTTP GET; y las peticiones action responden peticiones HTTP POST, PUT y DELETE.

Las peticiones tipo render son atendidas por métodos render en servlets REST. Los métodos render pueden atender tanto peticiones de un navegador web que son respondidas utilizando HTML o XHTML, y peticiones web services que son respondidas utilizando formato XML. Los métodos render en un servlet Cetia4 REST ( que extiende RestServlet ) no son heredados de la clase padre. En lugar de eso, son descubiertos durante la inicialización de la clase utilizando el API estándar de reflexión de java. Esto significa qeu dichos métodos deben adherirse a una convención a fin de ser descubiertos y utilizados. El método render más simple que puede ser creado en un servlet Cetia4 REST es el que se muestra en el siguiente código:

package com.example.forum.controller;
import com.acsinet_solutions.cetia4.controller.rest.RestServlet;
import com.acsinet_solutions.cetia4.controller.RenderContext;
public class TopicsServlet extends RestServlet
{
  public String render( RenderContext context )
  {
   return "display_topics";
  }
}

Un método render puede ser reconocido porque inicia con el prefijo "render" y regresa un valor de tipo java.lang.String. Los parámetros de un método render son dinámicos por naturaleza, pero comúnmente se recibirá por lo menos un argumento de tipo com.acsinet_solutions.cetia4.controller.RenderContext. En un ambiente de servlets, esta clase puede ser vista como un contenedor genérico para las referencias estándares hacia la petición, respuesta, y configuración del servlet ( objetos javax.servlet.http.HttpServletRequest, etc. ). RenderRequest ofrece métodos de conveniencia para accesar funcionalidad de estos objetos específicos del API de java servlets de forma genérica.

Un método render regresa una instancia de tipo java.lang.String como valor de retorno. Este valor hará referencia a la vista que desplegará la respuesta al cliente. Puede ser un valor absoluto ( que inicia con una '/' ) o un valor de ruta relativa. Un valor de ruta relativa - como el que se muestra en el código de ejemplo anterior "display_topics" - hace referencia a un archivo en un directorio por defecto con una extensión por defecto. El directorio por defecto depende del nombre administrativo del servlet, e inicia por defecto con el path "/WEB-INF/html" para peticiones web tradicionales ( a diferencia de peticiones web service ), y después continua con un directorio con el nombre del servlet REST.

El método render() creado con anterioridad responderá peticiones GET para el recurso básico representado por el servlet; en otras palabras, responderá peticiones hacia el URL http://example.com/forum/topics, pero no responderá peticiones GET hacia ninguno de sus subrecursos como http://example.com/forum/topics/234 o http://example/forum/topics/235/comments. Cómo responder a estos otros tipos de peticiones es examinado en el documento de tutorial.

El método render definido anteriormente también puede ser utilizado para atender una petición web service; un tipo de petición que espera XML como formato de respuesta. Esto puede ser logrado fácilmente utilizando la misma estrategia de paths relativos que fue explicada con anterioridad. En el caso de una petición a web service, una vista diferente es seleccionada; para el mismo ejemplo anterior, el directorio por defecto ahora es considerado bajo /WEB-INF/xml ( en lugar de /WEB-INF/html ) y el prefijo por defecto es .jspx ( porque ahora se están generando archivos XML ). Por lo tanto, pra el mismo ejemplo de código, el archivo de vista en este caso será /WEB-INF/xml/topics/display_topic.jspx. El framework Cetia4 reconoce entre una petición web tradicional y una peticion web service basándose en el header HTTP Accept. Un header HTTP Accept con valor "text/html" o que contenga "html" en cualquier parte del mismo será respondido de una forma tradicional ( y por lo tanto la vista bajo /WEB-INF/html será seleccionada ); en contraste, un header HTTP Accept de valor "application/xml" o "text/xml" será respondido como web service ( y por lo tanto la vista bajo /WEB-INF/xml será seleccionada ). Por lo tanto, es muy imortante para el cliente web service establecer apropiadamente este encabezado HTTP, o la petición podría no ser respondida de la forma deseada.

Copyright © ACSINET S.A. de C.V. 2000 - 2007 Derechos Reservados. Java™ is a trademark of Sun Microsystems in the United States and/or other countries All other products and services are trademarks of their respective owners.