Implementación de una fachada Web 2.0 RESTful habilitada por JSON usando WebSphere DataPower SOA Appliances

Este artículo le muestra cómo construir un servicio RESTful habilitado por JSON en un WebSphere DataPower Appliance mediante un puenteo con un servicio web de back-end SOAPful. Se incluye código REST/JSON de muestra para ejemplificar las mejores prácticas junto con explicaciones de su implementación y configuración.

Brien H. Muschett, Senior Software Engineer, DataPower Development Team, IBM

Brien Muschett es Senior Software Engineer del equipo de DataPower Development y trabaja en el desarrollo de software de IBM desde hace 16 años. Durante este tiempo, ha desarrollado soluciones de software para entornos incrustados, de escritorio y de servidores. Brien posee experiencia en desarrollo de sistemas operativos, reconocimiento del habla, desarrollo de síntesis del habla y desarrollo ESB.



04-08-2011

Introducción

La Transferencia de Estado Representacional (Representationsl State Transfer o REST) es una importante tecnología Web 2.0 que se ha convertido en una alternativa popular de otros servicios basados en Internet, como los servicios web basados en SOAP y Enterprise JavaBeans (EJB). Muchas empresas orientadas hacia Internet proporcionan servicios basados en REST; un escenario común es la exposición de una interfaz RESTful frente a un sistema legado o sistema par existente (servicios SOAPful). Este artículo explica brevemente lo que implica que un servicio sea "RESTful" y luego proporciona un ejemplo integral que muestra cómo usar un dispositivo SOA IBM® WebSphere® DataPower® XS40 o XI50 para exponer una fachada RESTful (con formato representacional JSON) y puentear un servicio web SOAPful existente.

Web 2.0 abarca la gran proliferación de nuevas tecnologías e incluye algunas completamente nuevas y otras antiguas pero modernizadas y potenciadas para su aplicación a Web 2.0. Existe una creciente demanda de usar estos nuevos protocolos y tecnologías para interactuar con sistemas empresariales existentes. DataPower se encuentra especialmente posicionado para Web 2.0 y SOA. DataPower puede prestar servicio a solicitudes Web 2.0, como mensajes ATOM feed o invocaciones REST y puentearlos a protocolos empresariales, como servicios web, JMS e incluso conectividad mainframe (por ejemplo, con IMS Connect). Este artículo desarrolla un caso en el que se puentean solicitudes de clientes REST que usan JSON como formato representacional a un sistema de back-end de servicios web SOAPful tradicional.

Generalidades de REST

REST es un término que inventó Roy Fielding en su tesis de doctorado y se refiere a un estilo arquitectónico para servicios y aplicaciones Web que manipulan contenidos de medios. Puede considerarse un conjunto de mejores prácticas para el uso de la especificación HTTP (RFC 2616) como protocolo a nivel de aplicación. No posee estándares o API y sus ingredientes principales se encuentran en todos los servicios y aplicaciones Web basados en HTTP. REST podría explicarse como un tipo de programación Web "orientado a objetos" en el que el recurso especificado por la URI es el objeto, el verbo HTTP especifica el método y los encabezados HTTP especifican los parámetros, por ejemplo, las consultas URI o Accept. Por último, el código de respuesta HTTP es el código de devolución. Por ejemplo, la siguiente solicitud HTTP RESTful tiene por resultado el código de respuesta HTTP 201 (creado):

PUT /library/book/9780596529260 HTTP 1.1 Content-Type:
                application/json Accept: text/xml .... { "name" : "Treasure Island }

Un proveedor de servicios web (o consumidor) prestará especial atención a los siguientes preceptos RESTful:

Recursos nombrados
El cómputo se realiza mediante recursos Web nombrados a través de URI.
  • Se denomina recurso a cualquier elemento lo suficientemente importante como para ser referenciado como un objeto en sí mismo, por ejemplo: /software/releases/1.0.3.tar.gz, /weblog/jim/2008/12/24/0300 o /bug/12345.
  • Los consumidores interactúan con los recursos usando sus URI y la interfaz uniforme.
Interfaz uniforme
Se accede a los recursos Web a través de una interfaz genérica que imita el patrón de almacenamiento persistente CRUD:
  • GET – Recuperar una representación de recurso.
  • POST -- Crear un nuevo recurso.
  • PUT – Modificar o crear un nuevo recurso (si el cliente puede crear URI).
  • DELETE – Eliminar un recurso existente.
  • HEAD -- Recuperar representación de sólo metadatos (pueden ser solamente los encabezados).
Representaciones de recursos interconectados
Los vínculos URL interconectan recursos y de esta manera conducen todas las transferencias de estados.
  • Las representaciones son hipermedios (tome en cuenta la dualidad de XHTML y microformatos).
  • Una red de recursos.
  • Axioma: "Los hipermedios como motor del estado de aplicaciones" -- Roy Fielding.
  • La ruta que sigue el cliente es, por consiguiente, el estado de aplicaciones y no una sesión HTTP en un servidor.
  • Las cookies rompen el modelo REST de transferencia de estados.
Sin estado
Cada solicitud existe independientemente sin correlación con el estado del extremo del servidor.
  • Los estados de un servidor se representan mediante recursos direccionables URI.
  • Cada solicitud HTTP existe en completo aislamiento y no depende de solicitudes previas.
  • El cliente pasa por distintos estados navegando en formatos representacionales (URI) o dirigiéndose a puntos de referencia conocidos.
  • Considere al "directorio en funcionamiento" FTP como una analogía.
  • Fácil distribución de una aplicación sin estado a través de servicios con cargas equilibradas.
  • El cliente se ocupa de gestionar el "estado de aplicaciones", mientras que el servidor gestiona el "estado de recursos".

El resultado de la aplicación de los preceptos RESTful no se limita a la simplicidad y consistencia en el desarrollo y la invocación de servicios web, sino que además brinda ventajas de rendimiento de servicios. Cuando se implementan servicios RESTful, estos pueden participar con naturalidad en el mecanismo de almacenamiento en caché HTTP. Por consiguiente, los intermediarios de almacenamiento en caché o los cachés de respuesta logran potenciar la información adicional proporcionada por el método HTTP y los encabezados de control de caché (incluyendo al encabezado last-modified [última modificación]) suministrados por el proveedor de servicios RESTful. Es así como la potenciación del almacenamiento en caché puede mejorar considerablemente el tiempo de respuesta. Asimismo, la naturaleza sin estado del servicio RESTful no sólo convierte al escalamiento horizontal en una tarea trivial, sino que además aliviana la carga en los equilibradores de cargas (no se requiere de afinidad entre sesiones) y permite una ejecución más eficiente de los intermediarios de almacenamiento en caché que conocen las aplicaciones debido a que no suele ser necesario procesar o analizar la carga útil.

Exposición de REST con DataPower

La Figura 1 muestra un panorama general de WebSphere DataPower exponiendo una fachada REST contra un servicio web SOAPful como back-end. El formato representacional (tipo de medio) que usa la fachada REST es JSON. La puerta de enlace multiprotocolo acepta las solicitudes del método RESTful (GET, PUT, POST, DELETE) del consumidor de servicios y luego transforma estas solicitudes en las solicitudes SOAP correspondientes, las cuales se envían al WS-Proxy (proxy de servicios web). El WS-Proxy es opcional, ya que las solicitudes SOAP podrían enviarse directamente al back-end, pero esta práctica se desaconseja totalmente debido a que la configuración podría requerir de monitoreo o seguridad en el futuro. Por lo tanto, la mejor práctica consiste en incluir un WS-Proxy como parte de la configuración de transformación REST.

Figura 1. Topología de un cliente RESTful que transmite JSON a DataPower, el cual media un servicio web SOAPful
Topología de un cliente RESTful que transmite JSON a DataPower, el cual media un servicio web SOAPful

Ejemplo DemoService

De aquí en más, este artículo usa un ejemplo común llamado DemoService para mostrar cómo DataPower expone una interfaz de servicios web RESTful, habilitada por JSON, a un back-end de servicios web SOAPful. El servicio web de muestra DemoService es un organizador de proyectos sencillo que permite la creación, edición y consulta de proyectos. Las operaciones disponibles en DemoService son las siguientes:

Operaciones disponibles en DemoService
OperaciónDescripción
createProjectCrea un proyecto en el servidor formado por un nombre de proyecto, una descripción y un identificador. El identificador se genera y devuelve en la respuesta.
updateProjectRealiza un cambio sobre un proyecto. Deben proporcionarse el identificador, el nombre y la descripción del proyecto.
getProjectObtiene el nombre y la descripción de un proyecto. En la solicitud debe proporcionarse el identificador del proyecto.
listProjectDevuelve todos los proyectos.
deleteProjectElimina un proyecto del servidor. En la solicitud debe proporcionarse el identificador del proyecto.

Las próximas secciones muestran cómo mapear estas operaciones a una interfaz REST conformada por todos los métodos HTTP (GET, POST, PUT y DELETE).

Instalación de DemoService

Descargue la aplicación de muestra DemoServiceproporcionada al final de este artículo y luego siga los pasos detallados a continuación para instalar DemoService.ear en WebSphere Application Server V6.1:

  1. Desde la consola Admin, seleccione Applications => Install New Application (Aplicaciones => Instalar nueva aplicación)
  2. Seleccione Browse (Navegar) y luego seleccione el EARDemoService, como muestra la Figura 2 a continuación.
  3. Seleccione Next (Siguiente).
    Figura 2. Instalación de la aplicación DemoService
    Instalación de la aplicación DemoService
  4. Haga clic en Step 3 en el menú izquierdo y haga clic en Finish (Finalizar).
  5. Espere a que se complete la instalación y haga clic enSave(Guardar).

Configuración de WS-Proxy

Siga los pasos detallados a continuación para crear manualmente el WS-Proxy:

  1. Desde el panel de control DataPower, seleccioneWeb Service Proxy => Add(Web Service Proxy => Agregar).
  2. Ingrese demo-service-proxy como nombre y seleccioneCreate Web service proxy(Crear proxy de servicio web).
  3. Cargue el archivo demoService.wsdl (incluido en el archivo de descarga proporcionado), seleccione off (desactivar) WS-Policy References (referencias de directiva de servicios web) y haga clic enNext, como muestra la Figura 5 a continuación.
    Figura 3. Configuración de WS-Proxy
    Configuración de WS-Proxy
  4. Seleccione el signo + correspondiente a Local Endpoint Handler (Controlador de punto final local) y a HTTP Front Side Handler (Controlador de lado frontal de HTTP).
  5. Ingrese http-9080 como Name (Nombre) y 9080 como Port Number (Número de puerto) y luego haga clic en Apply (Aplicar).
  6. Volviendo al panel de configuración WS-Proxy, seleccioneAdd(Agregar) en Edit/Remove (Editar/Eliminar), y luego Nexten la parte inferior.
  7. Guarde su configuración. Esto da por terminada la configuración de WS-Proxy.

Importación de ejemplo de configuración de DataPower

Siga los pasos detallados a continuación para importar la configuración DataPower a su dispositivo XS40 o XI50:

  1. En la Consola DataPower Admin, seleccione Administration => Configuration => Import Configuration (Administración => Configuración => Importar configuración).
  2. Haga clic enBrowse, seleccione web20restjson_dwa_export.zip (incluido en el archivo de descarga) y luego seleccione Next:
    Figura 4. Importación de dominio DataPower
    Importación de dominio DataPower
  3. SeleccioneImport(Importar).

Puerta de enlace multiprotocolo REST

Si usted se detuvo a mirar la definición de servicio de la puerta de enlace multiprotocolo (Multi-Protocol Gateway) seleccionando la pestaña Advanced (Avanzado), habrá observado un rótulo de opción llamado "Process messages whose body is empty" (Procesar mensajes con cuerpo vacío), como muestra la Figura 5 a continuación. Esta opción es útil para patrones de mensajes que incluyen solicitudes y respuestas sin cuerpo. Esto es común en los servicios web RESTful, donde los mensajes pueden o no incluir un cuerpo pero aún así se requiere la ejecución de la política de procesamiento para realizar las mediaciones. A diferencia de los servicios web SOAPful, que siempre poseen una carga útil (cuerpo de mensaje), los servicios web RESTful suelen poseer (aunque no siempre) un cuerpo de mensaje, como es el caso del método HTTP DELETE.

Como nuestra fachada RESTful soportará los métodos HTTP DELETE y GET, deberá configurar el servicio para soportar mensajes sin cuerpo. Si no selecciona esta opción, DataPower se establecerá predeterminadamente en un modo de procesamiento denominado "One way exchange pattern" (Patrón de intercambio unidireccional) en el que los mensajes fluyen directamente al servidor posterior, eludiendo toda regla de procesamiento. También deberá configurar el controlador frontal de HTTP para que acepte los métodos HTTP que desea que soporte su política. Además, como estamos usando JSON como formato representacional, los tipos de carga útil de solicitud y respuesta serán no XML.

Figura 5. Procesar mensajes con cuerpo vacío
Procesar mensajes con cuerpo vacío

Reescritura de la URL

DemoService especifica /DemoService/services/localDemoServiceSOAP como URI de servicio, mientras que los servicios web RESTful no usan las URI como punto final de servicios sino como el recurso para aplicar la interfaz uniforme. Debido a esta importante diferencia de utilización, se asoció a la puerta de enlace multiprotocolo una política de reescritura de URL, como muestra la Figura 6 a continuación. De esta manera, todas las URI RESTful entrantes se reescriben a una única URI de servicio SOAP.

Figura 6. Política de reescritura de URL asociada a la puerta de enlace multiprotocolo
Política de reescritura de URL asociada a la puerta de enlace multiprotocolo

Uso de verbos en REST

Al construir un servicio RESTful, una mejor práctica es configurar reglas de procesamiento para cada método HTTP. Esto se debe a que la interfaz uniforme REST puede ser aplicada a cada URI RESTful pero requiere de comportamientos de procesamiento diferentes, como HTTP DELETE en /library/book/12345679001 y HTTP GET en /library/book/12345679001.

La puerta de enlace multiprotocolo coincide con los métodos HTTP a través de la creación de una Match Action - Matching Rule (Acción de coincidencia – Regla de coincidencia) y luego especificando un Matching Type (Tipo de coincidencia) de "método HTTP" para cada verbo REST soportado por el servicio, como muestra la Figura 7 a continuación. Esta regla de coincidencia puede combinarse con cualquier otro tipo de criterio de coincidencia para crear reglas de procesamiento personalizadas basadas en URI y/o encabezados HTTP.

Figura 7. Puerta de enlace multiprotocolo que usa criterios de coincidencia con métodos HTTP
Puerta de enlace multiprotocolo que usa criterios de coincidencia con métodos HTTP

Las próximas secciones describen la implementación de la política de puerta de enlace multiprotocolo REST mostrada en la Figura 8. Estas secciones pueden usarse como ejercicios de desarrollo DataPower REST, como configuración en correcto funcionamiento para usar como punto de partida de otros proyectos REST, o simplemente como una muestra de una transformación de REST/JSON a SOAP con DataPower.

Figura 8. Política de procesamiento REST/JSON
Política de procesamiento REST/JSON

Las siguientes secciones se titulan con las reglas de procesamiento DataPower: POST, GET, DELETE y PUT. La implementación de cada regla de procesamiento se describe del mismo modo, a saber:

  • Carga útil de solicitud: Ejemplo de carga útil de solicitud REST usando JSON como formato representacional.
  • Carga útil de respuesta:E jemplo de carga útil de respuesta o encabezados REST.
  • Acciones: Se muestran imágenes que representan la regla de procesamiento con sus acciones de procesamiento. La numeración indica la secuencia de las acciones de procesamiento.
  • Listados de código: Para las hojas de estilo definidas en las reglas de procesamiento. Cada listado está numerado de acuerdo con los números de secuencia de la figura de Acciones correspondiente.
  • Comando Curl: Comando Curl de ejemplo que invoca el servicio REST con el método HTTP correspondiente.

POST

La regla de procesamiento POST equivale a la operación createProject de la API SOAP.

  • Carga útil de solicitud: Objeto de proyecto JSON
    Listado 1. Carga útil de solicitud POST
    { "description":"Research of ancient cultures",
                            "owner":"Alice" }
  • Carga útil de respuesta: Ninguna, pero el encabezado HTTP de ubicación debe proporcionar la URL del recurso recién creado.
  • Acciones:
    Figura 9. Regla de procesamiento de solicitud POST
    Regla de procesamiento de solicitud POST

    (1) Acción convert-http: Esta acción de conversión de HTTP especifica a JSON (Fig. 10 a continuación) como la codificación de mensaje que analiza y transforma el mensaje automáticamente en JSONx, un formato estándar interno de IBM para representar JSON como XML. Una vez que JSON se transforma en JSONx, se dispone de las capacidades de transformación DataPower usuales para continuar procesando el mensaje como XML, de ser necesario. El Listado 2 muestra el JSONx resultante de la carga útil de la solicitud JSON del Listado 1:

    Listado 2.
      <?xml version="1.0" encoding="UTF-8"?>
      <json:object
      xsi:schemaLocation="http://www.datapower.com/schemas/json jsonx.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx">
      <json:string name="description">Research of ancient
      cultures</json:string> <json:string
      name="owner">Alice</json:string>
      </json:object>
    Figura 10. JSON especificado como codificación de entrada predeterminada
    JSON especificado como codificación de entrada predeterminada

    (2) Transformación createProjJSONx2SOAP.xsl: Esta hoja de estilo personalizada proporcionada por el usuario transforma la carga útil del proyecto REST (ahora en formato JSONx) a la carga útil SOAP equivalente. La descripción del proyecto y el dueño se copian de la solicitud de mensaje JSONx.

    (3) Acción Setvar: Esta acción establece el encabezado SOAPAction en la http://datapower.ibm.com/demoService/createProject antes de que el mensaje se envíe al proxy de servicios web demoService.

    Regla de respuesta POST: transformación set-location-header.xsl: Esta hoja de estilo selecciona el ID de la respuesta SOAP y establece el encabezado HTTP Location (ubicación) con la URL en el recurso recién creado.

    Listado 4. set-location-header.xsl
    <?xml version="1.0"
       encoding="UTF-8"?> <xsl:stylesheet
       xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
       xmlns:dp="http://www.datapower.com/extensions"
       xmlns:dpquery="http://www.datapower.com/param/query"
       xmlns:prot="http://www.ibm.com/schema/twss/prototype"
       xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
       extension-element-prefixes="dp" exclude-result-prefixes="dp"
       version="1.0"> <xsl:template match="/">
       <xsl:variable name="quote">'</xsl:variable>
       <xsl:variable name="message"
       select="//*[local-name()='successMessage']/text()" />
       <xsl:variable name="id_begin" select="substring-after($message,
       $quote)" /> <xsl:variable name="id"
       select="substring-before($id_begin,$quote)" />
       <dp:set-http-response-header name="'Location'"
       value="concat('/projects/',$id)" /> </xsl:template>
       </xsl:stylesheet>

    Para probar el método REST POST proporcionado en el Listado 1 se requiere de una solicitud JSON de ejemplo. La carga útil se guardó como RESTPostRequest.json. Para enviar la solicitud a DataPower, use este comando Curl:

    curl --data-binary @RESTPostRequest.json
                            http://DPHOST:4801/projects/2 -v

    El indicador -v permite visualizar los encabezados devueltos por DataPower. No existe carga útil de respuesta, pero preste especial atención al encabezado Location, el cual devuelve la URL del proyecto recién creado. Este encabezado, por ejemplo, devolverá /projects/3 cuando se haya creado el tercer proyecto.

GET

La regla de procesamiento GET equivale a las operaciones getProject y listProject de la API SOAP. Ésta puede recuperar o bien un proyecto único o una lista/conjunto de proyectos.

  • Carga útil de solicitud: Ninguna.
  • Carga útil de respuesta: Proyecto JSON, lista de proyectos JSON
    Listado 5. Carga útil de respuesta de proyecto JSON GET
    { "id":2,
                            "name":"Astronomy Project", "owner":"Jennifer" }
    Listado 6. Carga útil de respuesta de lista de proyectos JSON GET
    [ { "id":2,
                            "name":"Astronomy Project", "owner":"Jennifer" } ]
  • Acciones:
    Figura 11. Regla de procesamiento GET
    Regla de procesamiento GET

    Transformación rest-get-to-soap.xsl:Esta hoja de estilo construye una solicitud SOAP para obtener un proyecto o una lista de proyectos. Ésta equivale a las operaciones SOAP getProject y listProject. Primero se recupera el ID de la URL y luego una carga útil SOAP listProjectRequest o getProjectRequest.

    Listado 7. rest-get-to-soap.xsl
    <?xml version="1.0"
                            encoding="UTF-8"?> <xsl:stylesheet
                            xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
                            xmlns:dp="http://www.datapower.com/extensions"
                            xmlns:dpquery="http://www.datapower.com/param/query"
                            xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                            extension-element-prefixes="dp" exclude-result-prefixes="dp"
                            version="1.0"> <xsl:template match="/">
                            <xsl:variable name="url"
                            select="dp:variable('var://service/URL-in')"/>
                            <xsl:choose> <xsl:when test="contains ($url,
                            '/projects/')"> <xsl:variable name="id"
                            select="substring-after($url,'/projects/')"/>
                            <soapenv:Envelope xmlns:soapenv=
                            "http://schemas.xmlsoap.org/soap/envelope/" xmlns:demo=
                            "http://datapower.ibm.com/demoService/">
                            <soapenv:Header/> <soapenv:Body>
                            <demo:getProjectRequest>
                            <demo:id><xsl:value-of
                            select="$id"/></demo:id>
                            </demo:getProjectRequest> </soapenv:Body>
                            </soapenv:Envelope> </xsl:when>
                            <xsl:otherwise> <soapenv:Envelope xmlns:soapenv=
                            "http://schemas.xmlsoap.org/soap/envelope/" xmlns:demo=
                            "http://datapower.ibm.com/demoService/">
                            <soapenv:Header/> <soapenv:Body>
                            <demo:listProjectsRequest>true</demo:listProjectsRequest>
                            </soapenv:Body> </soapenv:Envelope>
                            </xsl:otherwise> </xsl:choose>
                            </xsl:template> </xsl:stylesheet>

    (2) Acción Setvar: Esta acción establece el encabezado SOAPAction en la http://datapower.ibm.com/demoService/listProject antes de que el mensaje se envíe al proxy de servicios web demoService.

    (3) Acción de procesamiento avanzado Method Rewrite (Reescritura de métodos): Antes de enviar el mensaje SOAP al back-end, deberá reescribir el método del HTTP GET originador a HTTP POST, que es el formato esperado por el servicio SOAP. Esto se logra usando la acción de procesamiento avanzado Method Rewrite e incluso puede llevarse a cabo estableciendo var://service/protocol-method al valor POST.

    Regla de respuesta GET(1) listProjResp2JSONx.xsl: Cuando se haya recuperado la respuesta SOAP desde el back-end, ésta debe transformarse a una carga útil JSONx RESTful. El ID, la descripción y el dueño del proyecto se recuperan del mensaje SOAP de entrada y se utilizan para construir la respuesta JSONx REST. Cuando se devuelve una lista de proyectos, este proceso se repite.

    Listado 8. listProjRest2JSONx.xsl
    <?xml version="1.0"
     encoding="UTF-8"?> <xsl:stylesheet
     xmlns:dp="http://www.datapower.com/extensions"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     extension-element-prefixes="dp" exclude-result-prefixes="dp"
     version="1.0"> <xsl:template match="/">
     <json:array xsi:schemaLocation="http://www.datapower.com/schemas/json
     jsonx.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx">
     <xsl:for-each select="//*[local-name()='project']">
     <json:object> <json:number name="id">
    
     <xsl:value-of select="*[local-name()='id']" />
     </json:number> <json:string name="name">
     <xsl:value-of select="*[local-name()='name']" />
     </json:string> <json:string name="owner">
     <xsl:value-of select="*[local-name()='owner']" />
    
     </json:string> </json:object>
     </xsl:for-each> </json:array>
     </xsl:template> </xsl:stylesheet>

    Regla de respuesta GET(2) jsonx2json.xsl: Ahora que tenemos la carga útil convertida a JSONx, apliquemos la hoja de estilo jsonx2json.xsl proporcionada por DataPower para convertir el resultado a JSON, que es el formato esperado por el cliente. Para enviar una única solicitud GET a DataPower, use el comando Curl (el ID del proyecto es 2):

    curl -G http://DPHOST:4081/projects/2

    Para enviar una solicitud GET para obtener una lista de todos los proyectos, use este comando Curl. Se debe omitir el ID del proyecto:

    curl -G http://DPHOST:4081/projects

DELETE

La regla de procesamiento DELETE equivale a la operación removeProject de la API SOAP.

  • Carga útil de solicitud: Ninguna.
  • Carga útil de respuesta: Código de respuesta HTTP 204 (sin contenido).
  • Acciones:
    Figura 12. Regla de procesamiento DELETE
    Regla de procesamiento DELETE

    (1) Transformación rest-delete-to-soap.xsl: Esta hoja de estilo construye la carga útil SOAP para eliminar un proyecto. Equivale a la operación SOAP deleteProject. El ID del proyecto se recupera de la URL y luego se usa para construir la carga útil SOAP.

    Listado 9. rest-delete-to-soap.xsl
    <?xml version="1.0"
                            encoding="UTF-8"?> <xsl:stylesheet
                            xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
                            xmlns:dp="http://www.datapower.com/extensions"
                            xmlns:dpquery="http://www.datapower.com/param/query"
                            xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                            extension-element-prefixes="dp" exclude-result-prefixes="dp"
                            version="1.0"> <xsl:template match="/">
                            <xsl:variable name="url"
                            select="dp:variable('var://service/URL-in')"/> <xsl:variable
                            name="id" select="substring-after($url,'/projects/')"/>
                            <soapenv:Envelope
                            xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                            xmlns:demo="http://datapower.ibm.com/demoService/">
                            <soapenv:Header/> <soapenv:Body>
                            <demo:deleteProjectRequest>
                            <demo:id><xsl:value-of
                            select="$id"/></demo:id>
                            </demo:deleteProjectRequest> </soapenv:Body>
                            </soapenv:Envelope> </xsl:template>
                            </xsl:stylesheet>

    (2) Acción Setvar: Esta acción establece el encabezado SOAPAction en la http://datapower.ibm.com/demoService/deleteProject antes de que el mensaje se envíe al proxy de servicios web demoService.

    (3) Acción de procesamiento avanzado Method Rewrite: Antes de enviar el mensaje SOAP al back-end, deberá reescribir el método del HTTP DELETE originador a HTTP POST, que es el formato esperado por el servicio SOAP. Esto se logra usando la acción de procesamiento avanzado Method Rewrite e incluso puede llevarse a cabo estableciendo var://service/protocol-method al valor POST.

    Regla de respuesta DELETE(1) set-response-code.xsl: Una vez que la respuesta SOAP se recupera del back-end, ésta debe transformarse en un código de respuesta RESTful, el cual suele ser 204 (sin contenido) cuando se trata de DELETE. Para enviar una solicitud DELETE a DataPower, use el siguiente comando Curl:

    curl -X DELETE
                            http://DPHOST:4801/projects/2

PUT

La regla de procesamiento PUT equivale a la operación updateProject de la API SOAP.

  • Carga útil de solicitud: objeto de proyecto JSON
    Listado 10. Carga útil de solicitud PUT
    { "id":2, "name":"Astronomy Project",
                            "owner":"Jennifer" }
  • Carga útil de respuesta:ninguna
  • Acciones:
    Figura 13. Regla de procesamiento PUT
    Regla de procesamiento PUT

    (1) Acción convert-http: Esta acción de conversión de HTTP especifica a JSON (Fig. 10 a continuación) como la codificación de mensaje que analiza y transforma el mensaje automáticamente en JSONx, un formato estándar interno de IBM para representar JSON como XML. Una vez que JSON se transforma en JSONx, se dispone de las capacidades de transformación DataPower usuales para continuar procesando el mensaje como XML, de ser necesario.

    (2) Transformación updateProjJSONx2SOAP.xsl: Esta hoja de estilo transforma la carga útil de proyecto REST JSONx a la carga útil SOAP equivalente. Se copian el ID, la descripción y el dueño del proyecto de la solicitud JSONx REST.

    Listado 11. updateProjJSONx2SOAP.xsl
    <?xml version="1.0"
                            encoding="UTF-8"?> <xsl:stylesheet
                            xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
                            xmlns:dp="http://www.datapower.com/extensions"
                            xmlns:dpquery="http://www.datapower.com/param/query"
                            xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                            xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx"
                            extension-element-prefixes="dp" exclude-result-prefixes="dp"
                            version="1.0"> <xsl:template match="/">
                            <soapenv:Envelope
                            xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                            xmlns:demo="http://datapower.ibm.com/demoService/">
                            <soapenv:Header /> <soapenv:Body>
                            <demo:updateProjectRequest> <demo:project>
                            <demo:id> <xsl:value-of
                            select="/json:object/json:string[@name='id']" />
                            </demo:id> <demo:name> <xsl:value-of
                            select="/json:object/json:string[@name='description']" />
                            </demo:name> <demo:owner> <xsl:value-of
                            select="/json:object/json:string[@name='owner']" />
                            </demo:owner> </demo:project>
                            </demo:updateProjectRequest> </soapenv:Body>
                            </soapenv:Envelope> </xsl:template>
                            </xsl:stylesheet>

    (3) Acción Setvar: Esta acción establece el encabezado SOAPAction en la http://datapower.ibm.com/demoService/updateProject antes de que el mensaje se envíe al proxy de servicios web demoService.

    (4) Acción de procesamiento avanzado Method Rewrite: Antes de enviar el mensaje SOAP al back-end, deberá reescribir deberá reescribir el método del HTTP PUT originador a HTTP POST, que es el formato esperado por el servicio SOAP. Esto se logra usando la acción de procesamiento avanzado Method Rewrite e incluso puede llevarse a cabo estableciendo var://service/protocol-method al valor PUT.

    Regla de respuesta PUT(1) set-response-code.xsl: Una vez que la respuesta SOAP se recupera del back-end, ésta debe transformarse en un código de respuesta RESTful, que suele ser 204 (sin contenido) cuando se trata de PUT. Se requiere de una solicitud de ejemplo para probar el método PUT REST -- ver Listado 10. La carga útil se guardó como RESTPutRequest.json. Para enviar la solicitud a DataPower, use el siguiente comando Curl. Lo normal y esperado es obtener una respuesta en blanco:

    curl -X PUT RESTPutRequest.json
                            http://DPHOST:4801/projects/2

Conclusión

Este artículo explicó cómo encaja WebSphere DataPower en el espacio Web 2.0, proporcionó una visión general de REST, describió los patrones de uso recomendado para exponer REST y JSON con WebSphere DataPower e incluyó un ejemplo integral con una exportación de dominio DataPower y la aplicación de back-end de servicios web DemoService. Al finalizar este artículo, usted comprenderá qué es REST y contará con los conocimientos necesarios para desarrollar servicios REST en WebSphere DataPower y poder configurar su propio dispositivo Web 2.0.

Agradecimientos

El autor agradece a Robert Peterson de IBM por su trabajo en el artículo Implementing REST services with WebSphere DataPower SOA Appliances, el cual sentó las bases para el desarrollo de este artículo y para la construcción de las características de la versión 3.8.0 de DataPower.


Descargas

DescripciónNombretamaño
DataPower demo service configurationweb20restjson_dwa_export.zip480 KB
DataPower demo service configurationweb20restjson_soap.zip1580 KB

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=468387
ArticleTitle=Implementación de una fachada Web 2.0 RESTful habilitada por JSON usando WebSphere DataPower SOA Appliances
publish-date=08042011