4. Por qué REST? Optimización de tráfico Cacheable Accesible a cualquier cliente HTTP Claro caso de uso: Backend de aplicaciones para SmartDevices P o r q u é R E S T
7. RESTful Web Services Sintáxis universal para identificar los recursos (URI) Definición de unarepresentación del estado MIME TYPE: XML, Json.. Interfaz Uniforme(GET, POST, PUT, DELETE) Qu é e s R E S T
9. REST a la luz de GeneXus Business Components Insert, Read, Update, Delete Data Providers Read R E S T e n GENE XUS
10. Ejemplo Proveer una lista de recursos (con filtros) Lista de Productos Exponer un recurso para modificación Ingreso de orden de compras R E S T e n GENE XUS
22. Casos de Uso Aplicaciones backend para Smart Devices Integración de Aplicaciones GX Integración de externos con aplicaciones GX REST R E S T e n GENE XUS
23. Conclusión Tecnología: Apuesta a HTTP Casos de uso claros GeneXus: Proveerservicios REST a partir de Business Components y Data Providers C ONC L US I ÓN
Para empezarmencionarles un datointeresante.Los REST webservices son unaalternativa a SOAP, y cadacadavezmasservicios en internet hoyusan REST. Para citaralgunosejemplosconocidos, tenemos Twitter, Facebook, Flickr, deliciuous, los servicios de Yahoo y AmazonCloud Computing tambien se basa en APIs REST para brindar sus funcionalidades. Para hacer el deploy de aplicaciones tanto a Windows Azure como a Amazon se utilizan llamadas a servicios REST. Para monitorear el estado de mi aplicación y temas de configuración se hacen a traves de servicios Rest.Estos dos proveedores (Azure y Amazon) también proveen servicios de storage, esta comunicación se realiza a través de servicios REST tambien.Seguramentenosveamos en la situacion de tenerqueintegrarnos a aplicacionesqueproveen REST.Porotrolado, esposiblequequetengamos el requerimiento de quenuestrosserviciossean Restful.En estemarco, esque GX ha adoptadoestatecnologia, mi objetivo en estacharlaesjustamentemostrarlescomo GX aporta un valor agregado en el hecho de queademás de ser muyfacilhacer un servicio REST en GX, todo el conocimiento de negocios de la KB se incorpora de maneraautomatica en los servicios REST hechos con GX.
Cuales la necesidad / problemaquetenemospara la cual Rest esunasolución.Abocarnos REST en GXExtraerconclusiones.
Como les decia, REST es un estilo de diseño de webservices, y constituye una alternativa a SOAP.REST tiene una serie de caracteristicas que vamos a ver mas adelante, que justamente hacen que sea la mejor solucion para ciertos casos en los cuales hay que resolverlos con webservices.Esos casos son aquellos en los que la optimizacion de trafico es esencial y parte de la solucion.REST brinda la posibilidad de que la informacion sea cacheable, y accesible a cualquier cliente HTTP, es decir no se precisan de APIS o librerias particulares en los clientes.En el caso de los generadores para SmartDevices que vamos a liberar en Ev2, se optó por REST como solucion para el backend de dichas aplicaciones, es decir, los clientes que ejecutan en los dispositivos se alimentan de servicios REST. Esto es por que la conexión en estos aparatos puede ser mas limitada.
Lo quequeremoshaceresexponerdatos de unaaplicación o lo quevamos a llamar “recursos” o entidades, en la web, con unasalida con un formatoestándar, paraque sea interpretable por un programaqueejecutesobrecualquierplataforma o framework, e inclusosobrecualquiercliente HTTP (inclusodesde un telefonocelular).
Me parecio que la mejor manera de contarles lo que es REST es mostrarles como invoco al servicio REST que provee la lista de productos.En base a lo que hablamos, vamos a suponer que lo que quiero es exponer la lista de productos de mi empresa, para que cualquier cliente HTTP pueda acceder a ella.Para invocarlo solo hago un GET al servicio (comopuedenver en la imagen, se trata del header del request HTTP)Luegopodemosver el response HTTP del servicio.Es solamente un HTTP Response, que trae en el cabezal el status code y demas datos, y en el cuerpo la lista de productos, en este caso en formato Json.Veanque el mensaje no lleva envelopes (como en el caso de SOAP).La respuestatiene el producId, la descripcion, y una URI queindicadondeobtener el detalle de cadaproducto. Esta URI sirvepara “descubrir” comolocalizarotrosrecursos.
Entonces, para ir a una definición formal, REST es un estilo de arquitectura de software (no es como SOAP un protocolo), es un modelo orientado a recursos que va directo sobre HTTP.Cuando un webservice es Restful?Cuando se van a cumplir una serie de condiciones.Básicamente se va a cumplir que cada URL es la representación de un objeto, al que vamos a llamar recurso.Cada recurso se asocia a una URI, y cada recurso tienen n representaciones posibles, puede ser XML, Json. Además REST es un modelo cliente servidor sin estado. No se mantiene el estado en el servidor.El estado del recurso viaja en la representación. También en la representación se incluye la referencia a otros recursos relacionados, como vimos en la lista de productos, que estaba la referencia a cada producto en particular.También se caracteriza por tener una interfaz uniforme, es decir, un conjunto de operaciones bien definidas que voy a poder ejecutar sobre los recursos – métodos HTTP GET, POST, PUT, DELETE.
Con frecuencia estas operaciones se equiparan a las operaciones CRUD que se requieren para la persistencia de datos.Dado un recurso, un POST HTTP a su representación se puede equiparar con un create sobre la DB.Un GET HTTP se corresponde a un Read, un PUT HTTP sobre la representación se puede equiparar a un UPDATE sobre la DB, y un DELETE HTTP con un Delete sobre la DB.Bien, hasta aca hemos hablado de que es REST y que podemos resolver con REST.
En GeneXus tenemos la posibilidad de crear automáticamente servicios REST a partir de transacciones que sean Business Components y a partir de Data Providers.Es decir que el metodoCreate del BC podrá ser accedido mediante el método POST de HTTP, el metodoRead del BC a traves de un GET HTTP, el Update del BC a traves de un PUT HTTP, y el delete a traves del delete HTTP.Lo interesante de esto es que se va a ejecutar toda la businesslogic del BC cuando se le invoque, sea cual se el metodo HTTP con el cual se invoque.Los data providers son servicios REST de lectura.
Entonces, para que me sirve todo esto?Vamos a suponer que tenemos varias aplicaciones que corren en diferentes webapplications (o modulos), que queremos integrar, es decir, hacer que dialoguen a traves de servicios.Queremos resolver dos cosas..Acceder al catalogo de precios de los productos y habilitar la solicitud de ordenes de compras via web.Entonces, en mi kb tengo una transaccion de products otra de ordenes de compras, y customers.
Voy a empezar por exponer el recurso “lista de productos” como servicio REST.La manera de crear un servicio REST es muy sencilla, Mi transaccion debe ser Business Component, Y debo especificar la propiedad Expose as webservice – REST del Business Component.
Ok, entonces dado el servicio anterior, que se llama Product, puedoinvocarlo al mismohaciendo un GET HTTP, paraobtener lo siguiente,La lista de productos, dondetenemos el ID, el desc attribute – quees la descripcion – y una URI, quesirveparalocalizar el detalle del producto.Esto lo muestroaqui en formato XML, pero sin ninguncambio, solo con un parametroadicional se obtiene lo mismo en formato JSON.Tambien se puedeobtenermediante el mismo BC queestaexpuestocomo REST, el detalle del producto, haciendo un GET deProduct/PKEn la imagen lo tenemos en formato XML y Json.Veanqueprogramaresteservicioimplicariaarmar el response HTTP con el XML y/o el Json, segununaestructurapreestablecida. Masdificilaunseriaejecutarreglas de negocios de maneraprogramatica, en vez de aprovecharlasreglasquetiene el BC.
Un ejemplointeresanteesque se puedeobtenertambien la lista de productosporpagina, esdecir, haciendo un GET al servicio Product pasandocomoparametro la pagina y la cantidad de registros, me devuelve la paginacorespondiente.
Tambienesposiblefiltrarpor la FK. Porejemplo, en la transaccion de Orders el ProductIdes clave foranea. Es posiblepedirmediante un GET lasordenes de compras de tal o cualproducto.Esto se hacemediante un GET HTTP a Product/<productoId>/Orders
Ahoravamos a ver un caso en el cual me interesafiltrarporprecio y descripcion, y ademásordenarpor ambos en eseorden.Este DP me permite listar los productos con un Precio menor a &productPrice, y me devuelve la lista de los mismos ordenados por Precio. Si el &productPrice es vacio muestra la lista de Productos ordenados por Descripción.Para invocarlo, tendriaquehacer un GET http al servicio, quelleva el nombre del dataprovider, pasandocomoparametrodescripcion y precio.Veanqueprogramaresteservicioimplicariaarmar el response HTTP con el XML y/o el Json, segununaestructurapreestablecida. Hastaaquivimosejemplos de comopodemoshacerservicios REST paraacceder a ellosmediante un GET.Les voy a mostrar a continuacioncomoes un clienteGeneXuspara un servicio REST como el de los ejemplos…
Por ahora el cliente se programa de esta manera. Es solamente usar una variable de tipo HTTPClient para establecer la conexión al host donde reside el servicio, luego se hace un GET al servicio.La respuesta vendra en formato Json o XML, dependiendo de eso se puede hacer fromJson o fromXML para cargar la informacion en un SDT. Eso es todo.
Ws REST quepermite el ingreso de unaorden de compras.En estecasotenemosunatransaccion de nombre Orders quetambienpretendemosexponercomoservicio REST, estavezparapoderingresarunaorden en la base de datos.Veanque la orden de comprastiene el CustomerId, ProductId, ProductPrice, Qty, y una formula queesPrecioporCantidad.Tambientenemosunaregla error siprecio del productoes mayor que 100.
Enesteejemplovamos a vercomoingresarunaorden de compras a traves de REST.En estecasotenemos un servicio REST hecho en Ruby, corriendosobreWebrick, y un cliente Java corriendo en Tomcat.Este ejemploreune los dos casosquehemosestadohablando, es un webpanelquemediante un GET ejecuta el servicioquetrae la lista de productos. Puse en el medio de la comunicacion el tcptrace, parapoderver el dialogo entre cliente y servidor.En otrocasovamos a intentarhacer un POST a unaorden de compras con un producto con valor mayor a 100. me interesaquepuedanver la respuesta del servicio, que en el status code indica de un error, y que la recuperamosparamostrar el feedback al usuario.
Este es el clientequehace el POST al servicio Orders.Se trataigualque en el caso anterior de definiruna variable de tipoHTTPClientparaestablecer la conexion al servicio.Luego en un SDT con la estructura de la order guardo la informacion de la misma, Customer, ProductoFecha y cantidad. Mando al request HTTP la orden de compras, luegohago el POST al servicio.En la vueltaanalizo el status code y proceso la respuesta.En el procesamiento de la respuesta, vamos a tener el resultado de la ejecucion de lasreglas de negocios, paratomaracciones.
Resumiendo, tengo la posibilidad de invocar a la transaccion sin interfaz, expuestacomo un servicio REST.Esoimplica el disparo de lasreglas de negociosqueencapsula.En particular, para el control de concurrencia se lleva a caboun dialogoseudoconversacionalcomo en el caso de lastransacciones web con interfaz. Para hacer un update en la base de datos se debehacer un GET previamente, y luegocuando se efectua el update se controlaque no hayahabidocambios entre el GET y el save. Esto se resuelveinternamente.
Entonces,parairconcluyendo, REST esunaalternativa a SOAP para el diseño de web services, cuyapropuestaesreducir lo masposible el traficoqueviajapor la red, siendo el contenidoqueviajapor la red bastantemaslivianoque SOAP y mucho masfacil de cachear.Estoes ideal paracasos en los que el ancho de bandaeslimitado, como en el caso de los telefonoscelulares, fueporesoque se optóporestosservicioscomo backend paralasaplicaciones de dispositivosmoviles.Otrocaso de usoescomoestuvimosviendo en el ejemplo, la integración de aplicacionesGeneXus, usandoservicios REST GX y consumidores GX, aca lo que se puededestacarcomoventajaimportantees la sencillez de la solución.Otrocasoes el de integración con externos, a lo cual no noshemosabocado en estacharla. Los servicios REST GX pueden ser consumidos con cualquiercliente HTTP externo.En cuanto a consumirdesde GX servicios de terceros, en gralquienesproveen el serviciodisponen de APIs paraacceder a ellos, por lo cual lo podemoshacer a traves de external objects.
Conclusión Rest es más una vieja filosofía que una nueva tecnología. La filosofía REST apuesta al protocolo HTTP como base fundamental para resolver casos de integración, sobre todo apuesta a resolver casos críticos en los cuales el ancho de banda es limitado. “Rest no es una cura para todo”, hay casos de aplicación mas claros que otros, Tenemos claros casos de uso que hemos estado viendo, pero en definitiva es una tecnologia que marca una importante curva de crecimiento.En este marco, GeneXus nos permite abordar el tema de proveer servicios REST de una manera sencilla -sin complicarnos por los detalles técnicos que impone REST y abocarnos a programar las reglas de negocios.Esto hoy lo pueden probar en Ruby en Ev1, y se a liberar en Ev2 para java y NET.
