Este documento describe los principios de REST y su aplicación en Ruby on Rails. Explica conceptos clave como recursos identificables mediante URIs, interfaz uniforme basada en métodos HTTP, comunicación sin estado, representación de recursos y enlaces hipermedia. También compara REST con servicios web SOAP y describe cómo diseñar aplicaciones RESTful siguiendo buenas prácticas como dividir los datos en recursos y conectarlos mediante enlaces.
SEMINARIO: Servicios REST. Bases de la tecnología y soporte con Spring MVCParadigma Digital
En este seminario se impartirá una introducción al concepto detrás de la tecnología REST. Adicionalmente, se introducirá al asistente a la implementación de un servicio REST, usando para ello el stack que ofrece el framework Spring, y mas concretamente las nuevas versiones de Spring MVC”. Con este seminario abrimos el nuevo curso 2012/2013, en el que Paradigma irá cada tres semanas aproximadamente ofreciendo una temática nueva.
Más información: http://www.paradigmatecnologico.com/seminarios/seminario-servicios-rest-bases-de-la-tecnologia-y-soporte-con-spring-mvc/
Internet hoy en día, es un sistema muy grande, distribuido, y con piezas en cada uno de los rincones del mundo. Conectar cada uno de los componentes no es una tarea fácil, ni mucho menos sencilla. En esta charla hablaremos de los beneficios que la arquitectura de diseño REST le trajo a la web, mostrando ejemplos concretos sobre su uso, y casos de éxito. Además, realizaremos una introducción de los conceptos básicos, y mostraremos una serie de pasos y consejos para crear aplicaciones REST, y entender aquellas que se ofrecen a lo largo de la web. Finalmente, dedicaremos un momento a comentar sobre los principales agregados que tiene REST, que hacen de la arquitectura algo mejor y más completo. Hablaremos de autenticación y seguridad, paginado, manejo de errores, y más.
Los últimos diez años han visto unos cambios drásticos en la forma de entender y diseñar las arquitecturas para las aplicaciones web. REST irrumpió a principios de la década pasada como una técnica para modelar el interfaz de estas aplicaciones ganando notoriedad sobre otros conceptos y convirtiéndose en un estándar de facto. En la charla, intentaremos aterrizar esta filosofía de desarrollo para aquellos que nunca se han enfrentado a ella, al mismo tiempo que hablaremos de algunos temas algo más avanzados.
Una pequeña sinopsis de lo que trataremos:
1. Introducción
2. Modelo de madurez de Richardson
• HTTP
• Recursos
• Verbos
• HATEOAS
3. Estrategias de cacheo
4. Escalabilidad
5. Estrategias de testeo
SEMINARIO: Servicios REST. Bases de la tecnología y soporte con Spring MVCParadigma Digital
En este seminario se impartirá una introducción al concepto detrás de la tecnología REST. Adicionalmente, se introducirá al asistente a la implementación de un servicio REST, usando para ello el stack que ofrece el framework Spring, y mas concretamente las nuevas versiones de Spring MVC”. Con este seminario abrimos el nuevo curso 2012/2013, en el que Paradigma irá cada tres semanas aproximadamente ofreciendo una temática nueva.
Más información: http://www.paradigmatecnologico.com/seminarios/seminario-servicios-rest-bases-de-la-tecnologia-y-soporte-con-spring-mvc/
Internet hoy en día, es un sistema muy grande, distribuido, y con piezas en cada uno de los rincones del mundo. Conectar cada uno de los componentes no es una tarea fácil, ni mucho menos sencilla. En esta charla hablaremos de los beneficios que la arquitectura de diseño REST le trajo a la web, mostrando ejemplos concretos sobre su uso, y casos de éxito. Además, realizaremos una introducción de los conceptos básicos, y mostraremos una serie de pasos y consejos para crear aplicaciones REST, y entender aquellas que se ofrecen a lo largo de la web. Finalmente, dedicaremos un momento a comentar sobre los principales agregados que tiene REST, que hacen de la arquitectura algo mejor y más completo. Hablaremos de autenticación y seguridad, paginado, manejo de errores, y más.
Los últimos diez años han visto unos cambios drásticos en la forma de entender y diseñar las arquitecturas para las aplicaciones web. REST irrumpió a principios de la década pasada como una técnica para modelar el interfaz de estas aplicaciones ganando notoriedad sobre otros conceptos y convirtiéndose en un estándar de facto. En la charla, intentaremos aterrizar esta filosofía de desarrollo para aquellos que nunca se han enfrentado a ella, al mismo tiempo que hablaremos de algunos temas algo más avanzados.
Una pequeña sinopsis de lo que trataremos:
1. Introducción
2. Modelo de madurez de Richardson
• HTTP
• Recursos
• Verbos
• HATEOAS
3. Estrategias de cacheo
4. Escalabilidad
5. Estrategias de testeo
Webcast realizado para el MUG (Grupo de Usuarios de Microsoft, Buenos Aires, Argentina)
La temática giró alrededor del diseño y configuración de soluciones de Sharepoint.
Un WebService es una pieza de software identificada por un URI (Uniform Resource Identifier).
Su medio de comunicación se fundamenta en el uso de XML, TEXT, JSON
XML
XML Namespace, XML Schema, Xpath, XSLT.
HTTP, JSON
vortexbird
Repasaremos conceptos y principios para que una arquitectura sea RESTfull, se explicará cómo se ha plateado el framework Leophard para seguir estos y otros principios.
Webcast realizado para el MUG (Grupo de Usuarios de Microsoft, Buenos Aires, Argentina)
La temática giró alrededor del diseño y configuración de soluciones de Sharepoint.
Un WebService es una pieza de software identificada por un URI (Uniform Resource Identifier).
Su medio de comunicación se fundamenta en el uso de XML, TEXT, JSON
XML
XML Namespace, XML Schema, Xpath, XSLT.
HTTP, JSON
vortexbird
Repasaremos conceptos y principios para que una arquitectura sea RESTfull, se explicará cómo se ha plateado el framework Leophard para seguir estos y otros principios.
Presentación sobre "Introducción al desarrollo web moderno" ofrecida en el Evento organizado por el MUG en conjunto con la UAI Rosario, el día 05/06/2015.
En este documento analizamos ciertos conceptos relacionados con la ficha 1 y 2. Y concluimos, dando el porque es importante desarrollar nuestras habilidades de pensamiento.
Sara Sofia Bedoya Montezuma.
9-1.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0...Telefónica
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0xWord escrito por Ibón Reinoso ( https://mypublicinbox.com/IBhone ) con Prólogo de Chema Alonso ( https://mypublicinbox.com/ChemaAlonso ). Puedes comprarlo aquí: https://0xword.com/es/libros/233-big-data-tecnologias-para-arquitecturas-data-centric.html
2. Índice
REST o WS
Principios de REST
Direccionabilidad
Interfaz uniforme
Sin estado
Representación
abierta
Conectado
Conclusiones
3. Web humana y Web programable
Web humana
Visor Web, HTTP y HTML
HTML: presentaciones legibles
A evolucionado hacia XHTML, CCS, XML, …
Web programable
API, HTTP/SOAP, XML y ………
XML: Datos estructurados
Fuerte debate entre REST y “Big” Web Services
REST es
Una Web de datos accesible desde la Web humana
4.
5. Servicios o Recursos
“Big” Web Services (W3C)
SOA: Arquitectura orientada a servicios
APIs de Servicio de acceso a objetos remotos
RESTful Web Services
ROA: Arquitectura Orientada a Recursos
Interfaces Uniformes (métodos HTTP)
APIs de acceso y gestión de recursos Web
Los recursos se representan en XML, XHTML, JSON, ..
6. Que es REST
REpresentational StateTransfer.
Arquitectura de aplicaciones Web
Propuesta por Roy Fielding en su tesis doctoral (2000)
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Co-diseñador de HTTP y uno de los principales
desarrolladores del proyecto Apache
Arquitectura desacoplada y escalable
7. Rest y HTTP
REST es una abstracción que puede
implementarse sobre cualquier protocolo.
La mejor forma de implementarlo es sobre
HTTP.
Perfectamente adaptado a HTTP
Principal diferencia con SOAP
8. Principios sobre REST
Recursos Identificables (Addressability)
Interfaz de acceso uniforme
Comunicación sin estado (Statelessness)
Representación de los recursos
Hypermedia (Connectedness)
9. Identificador de recursos
Recurso: cualquier cosa en Internet que “merezca
la pena ser referenciada pos si misma”
Un fichero, un mapa, un usuario, un libro, un coche, …
Cada recurso se identifica con un URI
El URI (Permalink) da acceso al recurso
Cada URI añade valor a la red.
10. Ejemplo: Amazon S3
Servicio de almacenamiento de objetos.
Tiene 3 tipos de recursos:
1. Bucket-list: conjunto de buckets de un usuario
https://s3.amazonaws.com/
2. Bucket en particular: repositorio de objetos
https://s3.amazonaws.com/{Bucket}/
3. Objeto: posee metadato y valor
https://s3.amazonaws.com/{Bucket}/{Objeto}
11. Interfaz uniforme
Gestionar recursos solo con métodos HTTP:
GET (leer, copia solo lectura)
HEAD (cabecera)
PUT (crear)
POST (añadir)
DELETE (eliminar)
Posibilidad de hacer uso extensivo de
Cabeceras y códigos de respuesta de HTTP
Posibilidad de optimizar mediante el uso de
caches.
12. Amazon S3: Interfaz Uniforme
GET HEAD PUT DELETE
Bucket- Lista los
list buckets
de un
usuario
Bucket Lista los Crear Borrar
objetos bucket bucket
del
bucket
Objeto Obtener Obtener Crear y/o Borrar
valor y metadat Asignar Objeto
13. Representación de los recursos
Que es lo que obtenemos al acceder al URI del
recurso?
Una representación “bien conocida” y “abierta”
Pueden utilizar varios formatos:
HTML, XHTML, XML, JSON, PDF, FLASH, FLEX, ...
HTTP nos facilita el tipo (MiME) y permite
negociar el formato.
Habitualmente es XML.
14. Comunicación sin estado
El servidor NO mantiene el estado de la
conversación con cada cliente.
El estado esta explicito en las llamadas.
Cada estado se representa con una URI
Incrementa exponencialmente la escalabilidad.
Enfoque dispara y olvida (“fire and forget”).
Muy bajo acoplamiento
15. Ejemplos
Ejemplo stateful:
FTP
Existe un directorio implicito de trabajo
HTTP stateful
URI relativo: dependencia entre accesos consecutivos
Ejemplo statelessness:
HTTP con URLs absolutas
ATOM-PP y ATOM
Google Maps, Amazon S3, del.icio.us, …
16. Hypermedia
Las transiciones entre estados
Son siempre a través de enlaces
No hay que acordarse de los comandos de memoria
Usar un servicio:
similar a navegar por la Web
El servidor contiene la definición del servicio
Proporciona los enlaces como parte del recurso
El cliente es genérico
Modelo distribuido de fácil evolución.
17. REST conecta la Web humana y la
Web programable
Un servicio REST bien diseñado
También puede ser utilizado con un visor Web
Los recursos se presentan en el visor
Con CSS, XSLT, …..
Se usa navegando
haciendo click sobre las operaciones (enlaces)
Existe un problema con XHTML4
Los formularios solo soportan GET, POST
Quiza se solucione en XHTML5
18. REST y AJAX
El despliegue AJAX de un servicio REST
Son clientes en Javascript
que invocan el servicio con el interfaz uniforme
19. Diseño de una aplicación REST
1. Figure Out the Data Set
2. Resource Design:
Split the data set into resources
For each kind of resource
3. Name the resources with URIs
4. Expose a subset of the uniform interface
5. Design the representation(s) accepted from the client
6. Design the representation(s) served to the client
7. Connect Resources to Each Other
Integrate this resource into existing resources, using hypermedia links
and forms
8. Consider the typical course of events:
What’s Supposed to Happen?
9. Consider error conditions:
What Might Go Wrong?
20. Ventajas de RESTfull HTTP
Soporte universal y simple desde cualquier
lenguaje y plataforma.
Escalabilidad demostrada.
Soporte para redirección, cache, diferentes
representaciones.
Integración real para comunicación B2B.
Funciona con XML, pero también con otros
formatos (XHTM, JSON, ..).
21. Conclusiones
ROA: Resource Oriented Architecture
REST es el protocolo para la arquitectura del
mayor sistema distribuido del mundo (la web).
Mayor adopción
Adoptado casi unánimemente en el Web2.0
Google, del.icio.us, Amazon, Yahoo, ….
Las normas de “Big” Web Services están
todavía incompletas
RoR a discontinuado el soporte a “Big WS”
23. Controladores
Estamos habituados a:
/:controller/:action/:id
Que suele ser:
http://users/show/1
Te muestra el usuario con clave I
Tambien: /users/edit/1, /users/list/
42. Se basa en CRUD
Create, Read, Update, Delete
Generación automática del andamiaje.
Esto quiere decir, habitualmente:
create, show, edit, destroy
43. Diferencias
Verbo Rest Acción Antes
GET /users/1 Mostrar GET /users/show/1
DELETE /users/1 Borrar GET /users/destroy/1
PUT /users/1 Actualizar POST /users/update/1
POST /users/1 Crear POST /users/create
44. Existe otra parte
Hay que tener cuidado de no crear
Recursos basados en verbos
Reservar.
Autorizar
Reconfigurar.
Si no queda más remedio
mantenerlo separado.
45. En Rails
scaffold_resource script
Model
Controller
View
Route
RESTful Client:ActivereSource
46. scaffold_resource
Generación de recursos RESTful
./script/generate scaffold_resource
Genera Model, View, Controller, Routing
47. respond_to
Un mismo recurso responde con
diferentes formatos
respond_to do |format|
format.html { }
format.xml {
render :xml => @user.to_xml
}
end
48. Necesidad de autenticación
SSL no es suficiente.
Atom Publishing Protocol (Atompp)
RFC 5023
Complementario de Atom (eq. RSS)
Permite crear recurso sin saber su URL
49. ATOM
Collections: Conjuntos de Recursos que
pueden ser obtenidos parcialmente o
totalmente.
Services: Descubrimiento y descripción de
colecciones.
Modificar: Crear, editar y borrar recursos.
50. Ventajas de Rest
URLS limpios y estables.
múltiple representaciones
menos código
Controladores tipo CRUD
Diseño de aplicación más claro
Escalabilidad