![REST Web SERVICES ,[object Object],[object Object]](https://image.slidesharecdn.com/144restwebservices-090916114400-phpapp02/85/144-Rest-Web-Services-1-320.jpg)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a REST Web Services en 40
Semelhante a REST Web Services en 40 (20)
Mais de GeneXus
Mais de GeneXus (20)
Último
Último (16)
REST Web Services en 40
- 2. ¿Qué es un webservice ?
- 3. Hace mucho tiempo... HTTP, HTML, AJAX Navegadores Usuarios Clientes Locales WEB
- 5. Web Programable HTTP, HTML, AJAX Navegadores Usuarios HTTP, REST, SOAP Clientes Locales SERVICIOS WWW Composición de Servicios ( Mashups) WEB
- 6. REST
- 16. ROA ro ro ro ro ro ro ro ¿Cómo modelamos Recursos ? Entidades del sistema que pueden ser manipuladas Tenemos que pensar el comportamiento de los recursos mas allá del CRUD: CRUD es la interfaz no la Implementación ¿ GeneXus ? ¡ Transacciones !
- 18. ROA ro ro ro ro ro ro ro REST es diseño para consumo en contraposición al diseño para integración Es el B2C de los servicios La plataforma ES el Web
- 19. ROA ro ro ro ro ro ro ro Seguridad: HTTPS Identidad: HTTP Authentication + OAuth / OpenId Manejo de concurrencia: Status Headers (ETag) Modelado de flujos como cambios en Recursos
- 20. Ejemplos
- 21. Web APIs
- 22. Web APIs
- 23. GXBase API
- 24. GXBase API
- 25. GXBase API
- 27. REST en GeneXus (Consumo) (Consumo) BC1.Load() BC1.Save() BC1.Delete() DP1([Parm,...])
- 28. REST en GeneXus
- 29. REST en GeneXus
- 30. REST en GeneXus Demo
- 32. En conclusión...
- 33. WS* y la arquitectura REST ROA: “RESTful” web services. HTTP (XML, JSON, ...) Orientado a Recursos WS-* Stack: RPC-Style WEB SERVICES XML/XSD/SOAP Orientado a procesos
- 34. Resumiendo REST como opción de publicación API basada en recursos La lógica de negocios es parte del recurso ( reglas de negocio) Composición de servicios potencia mi solución
- 35. ¡Muchas Gracias!
Notas do Editor
- REST Web Services
- Web Programable
- Inicialmente tenemos la visión tradicional de las aplicaciones en las que tenemos aplicaciones en clientes locales, aisladas y por otro lado las "paginas WEB"que evolucionan la tecnología dentro del browser y funcionan conectadas a servidores que entregan paginas o parte de las mismas y había una clara distinción entre las dos cosas.
- El fenómeno que aparece a continuación es análogo a lo que sucede cuando se comienza con el empaquetamiento de funciones en bibliotecas en los lenguajes de programación y nacen los frameworks de aplicaciones.De la misma manera se comienzan a utilizar Datos, de distinta procedencia, para enriquecer la aplicación, combinando datos de diversas fuentes con los propios logro una aplicación mas útil. El ejemplo canónico son los Mapas, pero también hay otros ejemplos, fuera de la información geográfica, uso de perfiles ( notablemente facebook o openid ) login, etc. El fenómeno que aparece a continuación es análogo a lo que sucede cuando se comienza con el empaquetamiento de funciones en bibliotecas en los lenguajes de programación y nacen los frameworks de aplicaciones.De la misma manera se comienzan a utilizar Datos, de distinta procedencia, para enriquecer la aplicación, combinando datos de diversas fuentes con los propios logro una aplicación mas útil. El ejemplo canónico son los Mapas, pero también hay otros ejemplos, fuera de la información geográfica, uso de perfiles ( notablemente facebook o openid ) login, etc.
- Así llegamos a el escenario actual que todavía se esta desarrollando , donde las aplicaciones locales/desconectadas tienden a ser minoría, y los clientes usan datos externos, y a su vez los propios servicios se componen de datos de otros servicios (Mashups)Básicamente, todas las aplicaciones consumen servicios y como veremos mas adelante, muchas producen o publican información también.
- En este escenario están los servicio REST
- Que es Rest ?ReST viene de REpresentational State TransferEs una implementación de Servicios web usando los principios y las facilidades del protocolo HTTPEl término fue introducido por Roy Fielding en 2000 en su disertación de doctorado.Es al mismo tiempo una tecnología de implementación y una manera de diseñar los servicios.
- Primero vamos a ver la parte de implementación , para luego ver como impacta en el diseño el marco de servicios.
- REST es un protocolo basado en Recursos ¿Qué es un recurso ? Un recurso es cualquier cosa que nosotros queramos poner accesible en el web . Comúnmente son las Entidades y Por ejemplo Clientes, Documentos, Artículos , etcA su vez los recursos están identificados por un URI a través de la cual puedo obtener una representación del recurso o de una lista de recurso en el caso de los libros.
- Como obtengo estas representaciones ?Usando el protocolo ya existente el HTTP, mediante un get a la URI del recurso obtengo su representación por defecto.En este caso es XML Observemos la otra característica : los recursos tienen enlaces que me permiten navegar de uno a otro sin ninguna descripción o meta-data externa esto permite el "auto-descubrimiento"
- Otra ventaja es el uso de los cabezales de HTTP ( al igual que lo hace cualquier pagina web ) para implementar el Cache - controlando si quiero cache- eso puede ser a nivel del browser, o de un servidor ProxyTambién la autenticación se puede implementar con los mismos cabezales de httpy se puede realizar la lectura condicional ( quiero este recurso , si cambio después de la ultima vez que lo leí) usando Last-modified e If-modified-since
- Los verbos de HTTP permiten tener una interfaz uniforme , la misma, no importa el servicio, lo cual es muy bueno.Resumiendo, los métodos para los cuales se usan los verbos :GET Read , es seguro y esta garantido que no tiene efectos secundariosPOST Crea un recurso , el POST es "no seguro" en el sentido que los efectos no están definidos y dependen del servicio y no se puede realizar dos vecesPUT es Update, actualización es IDEMPOTENTE o sea se puede realizar varias llamadas o una el resultado es el mismoFinalmente el DELETE es usado para borrar y también es Idempotente .
- Resumiendo:REST es una manera de diseñar e implementar Web Services , basado en recursosCada recurso se identifica con una URLPara operar en esas url se usan los métodos del HTTPEsto recursos se transmiten como representaciones , usualmente en XML o JSON, pero puede también ser HTML o formatos binarios, dependiendo de la necesidad de la aplicación , incluso se pueden publicar recursos en varios formatos ( con mas de una representación)
- REST como arquitecturaLa tecnología ReST lleva asociada una manera de diseñar la interface de servicios. La orientación a Recursos contrasta con la orientación a Procesos o los servicios RPC que tradicionalmente vemos.
- Para volver a enumerar los principios básicos de la arquitectura ROA:Direccionable - Los recursos tienen una uri unicaSin estado - No se necesita un estado del server para realizar ninguna operación, esta todo en la representación y el llamado HTTPInterfaz uniforme -El GET siempre obtiene el recurso, y los demás métodos se comportan igual, no es necesaria una declaración de los servicios a nivel de firma de métodos para saber como usarlos.Conectado - Los servicios se referencian entre si para permitir navegabilidad dentro de la aplicación,
- CRUD es la Interfaz del REST , pero ¿Que modelamos detrás de los servicios?
- Como presento estas interfaces, por un lado permito la lectura de entidades de mi sistema, como “Pull” polling sobre el estado La contracara y el complemento esta en el push, es decir la notificación a pedido, como complemento de REST están los WEB Hooks que permiten una notificación a una URL arbitraria cuando surge un evento, esto esta también emparentado con el REST ya que abre la cancha en el mismo sentido, YO no se necesariamente para que van a usar estas notificaciones . Proveo el servicio y espero que surjan maneras innovadoras de aprovecharlo.
- Modelamos las entidades del negocio, preparamos interfaces no con el objetivo de integrarse con plataformas especificas ( para algo que hemos planeado ) , aunque eso tambien entra dentro de lo que ReST sirve. Sino para lo que no anticipamos, abrimos la interface para el consumo , con herramientas, plataformas y lenguajes que no anticipamos, para usos imprevistos que quizas encuentren valor en donde no lo creiamos posible. Esto es publicacion para el consumo. Nos sumamos al web
- Todo se puede modelar en base a Recursos Simple Transporte existente Seguridad existente Bibliotecas exiserntes Metaforas conocidas (CRUD) Escalable en el WEB con herramientas usadas hoy
- Ahora veamos algunos ejemplos de como se esta usando REST
- Existen muchas aplicaciones WEB que ofrecen servicios de SaaS en este ejemplo vemos una de facturación y cobro con una buena interfaz web
- Esta misma aplicación web tienen detrás una api rest ( sobre la cual ella misma funciona) que ademas ofrece a sus clientes como un enorme valor agregado: Si tengo una plataforma particular para la que no existe un cliente , lo hago. Si quiero integrarlo con mi sistema , también, la misma potencia que cualquier api de servicios pero que modela todo como recurso, es liviana, sencilla y rápida.
- Otra aplicacion interesante que podemos ver es el GeneXus Server , que ya habran visto, en esto tambien se esta trabajando , una api REST para el server . Aqui vemos el directorio /help donde podemos ver el catalogo de recursos que expone el server.
- Solo dos ejemplos breves de como se trabaja esto, primer punto de entrada un listado con un GET de todas las KBs GeneXus que están hosteadas en ese servidor. A partir de ahí puedo listar los objetos de la KB, filtrar por tipo hasta llegar...
- Al objeto propiamente dicho donde obtengo el contenido completo del objeto para poder trabajar con el. Esto tiene gran potencial de integración de KB con otros productos, servicios de alerta , etc.
- Como implementamos ReST en GeneXus ? Como habiamos dicho las Transacciones (Entidades) del sistema se modelan como recursos, a traves de los Business components. Tambien podemos exponer recursos a traves de Dataproviders cuando la generacion implica algo mas complejo Soportando las representaciones que hoy ya existen en la X Evolution 1 para serializacion de BCs y SDTs Con un uso de ReST pragmatico, siguiendo las recomendaciones de la arquitectura Rest siempre que tenga sentido en el contexto y no implique excesiva complejidad en el uso.
- Del lado del consumo desde GeneXus , se vera como se ven objetos externos, con alguna metadata que ayude a publicar esto para consumirlo como BCs o DPs regulares.
- Ahora veamos algunos ejemplos de como se esta usando REST
- Comparando los servicios web tradicionales , podemos ver las diferencias mas importantes con ReST: Los servicios de WS* Stack están basados en un mecanismo de llamado a procedimientos, apoyados en XML en la que se basan para describir, la interface (WSDL) , indicar los métodos y los datos (SOAP) Están fuertemente orientados a procesos. Los servicios ROA están basados en las técnicas REST usan HTTP como protocolo base y usan los métodos del HTTP Están fuertemente orientados a los Recursos
- Rest como opcion de publicacion de datos en forma de recursos y sus relacionesLa logica de negocios forma parte del recurso Posibilidad de componer servicios; juntando datos de diversos proveedores para potenciar mis soluciones