Este documento proporciona una guía sobre cómo diseñar una API RESTful. Explica conceptos clave como recursos, verbos HTTP, códigos de estado, autenticación, representación de mensajes, paginación e hipermedia. También recomienda herramientas y buenas prácticas como la documentación, versionamiento y el uso de enlaces para navegar entre recursos.
Workshop sobre APIs realizado el 27 de abril en el Centro de Innovación de BBVA. En este evento hemos visto los detalles del funcionamiento, gestión de errores y conceptos de seguridad aplicados a APIs.
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
Workshop sobre APIs realizado el 27 de abril en el Centro de Innovación de BBVA. En este evento hemos visto los detalles del funcionamiento, gestión de errores y conceptos de seguridad aplicados a APIs.
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
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.
A veces, parece fácil definir una API pero la experiencia indica que la mayor parte de los problemas vienen precisamente de la mala definición de la misma. En el taller de definición de Apis, aprenderemos a definir correctamente una APi Restful, caules son los parámetros aconsejables a tener en cuenta, y se analizará un ejemplo de una API con un servicio GET, POST, PUT y DELETE. Para realizar el taller se utilizará el lenguaje RAML y la herramienta api designer de Mulesoft.
Presentación que muestra como definir una API Rest con RAML, definiendo los servicios GET/PUT/POST... Se utilizarán las herramientas de Mulesoft para diseñar la API con ApiDesigner
Descubriendo Ruby on Rails (Desarrollo Agil de Aplicaciones Web)lenny
Esta es la presentación correspondiente a la charla "Descubriendo Ruby on Rails: Desarrollo Agil de Aplicaciones Web" dictada el 5 de Junio de 2007 por Juan Maria Martinez Arce y Carlos Kozuszko, ambos miembros de INSIGNIA (www.insignia4u.com); en el marco de la "Semana de la Ingenieria 2007".
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.
A veces, parece fácil definir una API pero la experiencia indica que la mayor parte de los problemas vienen precisamente de la mala definición de la misma. En el taller de definición de Apis, aprenderemos a definir correctamente una APi Restful, caules son los parámetros aconsejables a tener en cuenta, y se analizará un ejemplo de una API con un servicio GET, POST, PUT y DELETE. Para realizar el taller se utilizará el lenguaje RAML y la herramienta api designer de Mulesoft.
Presentación que muestra como definir una API Rest con RAML, definiendo los servicios GET/PUT/POST... Se utilizarán las herramientas de Mulesoft para diseñar la API con ApiDesigner
Descubriendo Ruby on Rails (Desarrollo Agil de Aplicaciones Web)lenny
Esta es la presentación correspondiente a la charla "Descubriendo Ruby on Rails: Desarrollo Agil de Aplicaciones Web" dictada el 5 de Junio de 2007 por Juan Maria Martinez Arce y Carlos Kozuszko, ambos miembros de INSIGNIA (www.insignia4u.com); en el marco de la "Semana de la Ingenieria 2007".
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
(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.
(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.
17. 0: The Swamp of POX
GET
http://srv.com/addin/auto-‐harvest/end-‐job/:id/
errors/:errors_messages
http://srv.com/addin/auto-‐harvest/start-‐job/:id
19. Uniform Interfaces
• Identificación recursos.
• Manipulación de recursos a través de su
representación.
• Mensajes auto-descriptivos.
• Hypermedia como motor del estado de la
aplicación (HATEOAS).
25. Uniform Interfaces
• Identificación recursos.
• Manipulación de recursos a través de su
representación.!
• Mensajes auto-descriptivos.
• Hypermedia como motor del estado de la
aplicación (HATEOAS).
30. GET /personas Obtener
lista
de
personas
POST /personas Agregar
una
persona
DELETE /personas/:id Eliminar
una
persona
GET /personas/:id Obtener
una
persona
PUT /personas/:id Actualizar
una
persona
GET /personas/:id/contactos Obtener
los
contactos
de
una
persona
POST /personas/:id/contactos Agregar
un
contacto
a
una
persona
POST /personas/subirImagen Subir
una
imagen
34. Uniform Interfaces
• Identificación recursos.
• Manipulación de recursos a través de su
representación.
• Mensajes auto-descriptivos.!
• Hypermedia como motor del estado de la
aplicación (HATEOAS).
41. Uniform Interfaces
• Identificación recursos.
• Manipulación de recursos a través de su
representación.
• Mensajes auto-descriptivos.
• Hypermedia como motor del estado de la
aplicación (HATEOAS).
42. HATEOAS
Clients make state transitions only through
actions that are dynamically identified
within hypermedia by the server. !
Except for simple fixed entry points to the
application, a client does not assume that
any particular action is available for any
particular resources beyond those
described in representations previously
received from the server.