Principios básicos de la Arquitectura Rest, haciendo especial hincapié en las 6 restricciones que permiten crear API altamente escalables (Uniform Interface, Stateless, Cacheable, Client-Server, Layered System y Code on Demand).
Estas restricciones son la base de la Arquitectura REST y aplicarlas nos ayudaran a conseguir buenos diseño: correcto nombrado de los servicios, recursos, aplicar el método (GET, POST, PUT, DELETE) apropiado a la acción, descubrir recursos basándonos únicamente en las respuestas del servidor (HATEOAS), ..
Además, conoceremos el Modelo de Madurez Richarson que nos permite conocer en que punto nos encontramos dentro de la arquitectura, algunos antipatrones de diseño y ejemplos de API REST (Twitter, Facebook).
Resumen del Rational Unified Process (RUP) para la materia de Análisis y Diseño de Sistemas de Información (INF - 162) de la carrera de Informática de la Universidad Mayor de San Andrés
APIs, REST e RESTful: O que os programadores precisam saber? - Marcos Echevar...Tchelinux
A arquitetura das aplicações web vem mudando ao longo do tempo, não basta só sabermos fazer requests e esperarmos um json de retorno. Entender o conceito por trás das APIs e as vantagens do padrão RESTful farão toda a diferença na hora de desenvolver aplicações "elegantes".
Marcos Echevarria é Marcos Echevarria é mestre em Ciência da Computação pela Universidade Católica de Pelotas. Desenvolve sistemas web há mais de 10 anos, tendo liderado equipes em projetos de médio e grande porte em empresas nacionais e internacionais. Atualmente é CEO na empresa Be Mobile e professor na Universidade Católica de Pelotas, onde leciona as disciplinas de Algoritmos e Engenharia de Software.
Para mais informações:
https://twitter.com/quinhodev
Continuous Deployment Practices, with Production, Test and Development Enviro...Amazon Web Services
With AWS companies now have the ability to develop and run their applications with speed and flexibility like never before. Working with an infrastructure that can be 100% API driven enables businesses to use lean methodologies and realize these benefits. This in turn leads to greater success for those who make use of these practices. In this session we'll talk about some key concepts and design patterns for Continuous Deployment and Continuous Integration, two elements of lean development of applications and infrastructures.
Resumen del Rational Unified Process (RUP) para la materia de Análisis y Diseño de Sistemas de Información (INF - 162) de la carrera de Informática de la Universidad Mayor de San Andrés
APIs, REST e RESTful: O que os programadores precisam saber? - Marcos Echevar...Tchelinux
A arquitetura das aplicações web vem mudando ao longo do tempo, não basta só sabermos fazer requests e esperarmos um json de retorno. Entender o conceito por trás das APIs e as vantagens do padrão RESTful farão toda a diferença na hora de desenvolver aplicações "elegantes".
Marcos Echevarria é Marcos Echevarria é mestre em Ciência da Computação pela Universidade Católica de Pelotas. Desenvolve sistemas web há mais de 10 anos, tendo liderado equipes em projetos de médio e grande porte em empresas nacionais e internacionais. Atualmente é CEO na empresa Be Mobile e professor na Universidade Católica de Pelotas, onde leciona as disciplinas de Algoritmos e Engenharia de Software.
Para mais informações:
https://twitter.com/quinhodev
Continuous Deployment Practices, with Production, Test and Development Enviro...Amazon Web Services
With AWS companies now have the ability to develop and run their applications with speed and flexibility like never before. Working with an infrastructure that can be 100% API driven enables businesses to use lean methodologies and realize these benefits. This in turn leads to greater success for those who make use of these practices. In this session we'll talk about some key concepts and design patterns for Continuous Deployment and Continuous Integration, two elements of lean development of applications and infrastructures.
You have heard how containers are great for running microservices, but what is needed to get microservices to run in production at scale? In this session, we explore the reasoning and concepts behind microservices and how containers simplify building microservices based applications. We will show how you can easily launch microservices on Amazon EC2 Container Service and how you can use ELB and Route 53 to easily do service discovery between microservices.
Presented by: Danny Fezer, Solutions Architect, Amazon Web Services
Customer Guest: Liz Duke, Technical Delivery Manager, Irdeto
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Oswaldo Hernández
SISTEMA WEB PARA LA GESTIÓN DE PERMISOS DEL
PERSONAL DE LA ZONA EDUCATIVA DEL ESTADO SUCRE
PERIODO 2015-2016/
CUMANÁ ESTADO SUCRE
DIAGRAMA DE CLASES
DIAGRAMA DE SECUENCIA
PATRONES DE DISEÑO
Documento de Estándares
de Interfaz Gráfica
Introdução ao conceito de APIs RESTful. Características, boas práticas e o que é importante se levar em consideração durante o desenvolvimento de uma API RESTful.
Aborda utilização de verbos HTTP, códigos de status, headers, controles de hipermídia, formatos de representação entre outros.
Especificación de Arquitectura de SoftwareSoftware Guru
El objetivo de la plática es mostrar con un ejemplo como especificar la arquitectura de un sistema.
Hoy en día hay varios libros de Arquitectura de software que nos muestran: Que debemos hacer, Que podemos usar pero pocos nos dan un ejemplo concreto.
Esta platica está dirigida a aquellos colegas que quieren iniciar en el rol de Arquitecto de Software, que tienen la experiencia y conocimientos pero tienen duda de como plasmar sus decisiones de diseño ó se preguntan si su diseño es suficiente y correcto.
En esta platica se desarrolla en 2 partes:
En la 1ª. se repasaran algunos conceptos relativos a la práctica de Arquitectura tales como objetivo, requerimientos no funcionales, riesgos, restricciones, patrones, vistas, etc.
En la 2ª. parte se mostrará como hacer una especificación de Arquitectura de un caso real pero acotado.
Al final espero que el participante se quede con una referencia que sirva para mejorar su práctica de Diseño de Arquitectura.
You have heard how containers are great for running microservices, but what is needed to get microservices to run in production at scale? In this session, we explore the reasoning and concepts behind microservices and how containers simplify building microservices based applications. We will show how you can easily launch microservices on Amazon EC2 Container Service and how you can use ELB and Route 53 to easily do service discovery between microservices.
Presented by: Danny Fezer, Solutions Architect, Amazon Web Services
Customer Guest: Liz Duke, Technical Delivery Manager, Irdeto
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Oswaldo Hernández
SISTEMA WEB PARA LA GESTIÓN DE PERMISOS DEL
PERSONAL DE LA ZONA EDUCATIVA DEL ESTADO SUCRE
PERIODO 2015-2016/
CUMANÁ ESTADO SUCRE
DIAGRAMA DE CLASES
DIAGRAMA DE SECUENCIA
PATRONES DE DISEÑO
Documento de Estándares
de Interfaz Gráfica
Introdução ao conceito de APIs RESTful. Características, boas práticas e o que é importante se levar em consideração durante o desenvolvimento de uma API RESTful.
Aborda utilização de verbos HTTP, códigos de status, headers, controles de hipermídia, formatos de representação entre outros.
Especificación de Arquitectura de SoftwareSoftware Guru
El objetivo de la plática es mostrar con un ejemplo como especificar la arquitectura de un sistema.
Hoy en día hay varios libros de Arquitectura de software que nos muestran: Que debemos hacer, Que podemos usar pero pocos nos dan un ejemplo concreto.
Esta platica está dirigida a aquellos colegas que quieren iniciar en el rol de Arquitecto de Software, que tienen la experiencia y conocimientos pero tienen duda de como plasmar sus decisiones de diseño ó se preguntan si su diseño es suficiente y correcto.
En esta platica se desarrolla en 2 partes:
En la 1ª. se repasaran algunos conceptos relativos a la práctica de Arquitectura tales como objetivo, requerimientos no funcionales, riesgos, restricciones, patrones, vistas, etc.
En la 2ª. parte se mostrará como hacer una especificación de Arquitectura de un caso real pero acotado.
Al final espero que el participante se quede con una referencia que sirva para mejorar su práctica de Diseño de Arquitectura.
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/
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
Building Automated REST APIs with PythonJeff Knupp
Writing REST APIs with ORMs and web frameworks is a chore. I'm lazy, and I don't want to write boring code. In this talk, I'll go over what REST APIs are, why they're useful, and why we should never have to write one from scratch again.
By the end of this talk, we'll have achieved developer Nirvana: a RESTful API service and Admin interface for existing databases *without writing any code*.
Introducción a la Arquitectura de Software.
Géneros Arquitectónicas
Estilos Arquitectónicos.
Diseño Arquitectónico.
Evaluación de los diseños alternativos para la Arquitectura.
SOA es un concepto de diseño de arquitectura que describe un sistema o software en términos de servicios (considerados como componentes) y la relación entre éstos (denominada composición).
Con SOA, los sistemas son altamente escalables ya que reflejan el negocio de la organización y utilizan capacidades distribuidas bajo el control de diferentes propietarios y dominios. Lo que provee una forma bien definida de ofrecer, descubrir, interactuar y usar dichas capacidades para producir los efectos deseados de manera consistente y medible.
2. Arquitectura REST 2|
Índice
Qué no es REST
Introducción
Restricciónes
Richardson Madurity Model
Rest Anti Patterns
Seguridad
Documentación
Algunos Frameworks Java y PHP
Demo Time
Q&A
3. Arquitectura REST 3|
REST NO ES …
REST no es un tecnología.
REST no es un framework.
REST no es un patrón de diseño.
REST no es un protocolo.
REST no es un estándar.
Arquitectura REST
4. Arquitectura REST 4|
¿QUÉ ES REST?
REST is a coordinated set of architectural
constraints that attempts to minimize latency
and network communication while at the same
time maximizing the independence and scalability
of component implementations.
Arquitectura REST
Roy Fielding
Tesis Doctoral
Architectural Styles and the Design of Network-
based Software Architectures, University of
California, Irvine, 2000
5. Arquitectura REST 5|
DESCRIPCIÓN GENERAL
REST == REpresentational State Transfer
Basado en Recursos (Elemento de información)
Representación (Formato de la información)
Restricciones:
Client-Server
Stateless
Cacheable
Uniform Interface
Layered System
Code-on-demand
Arquitectura REST
6. Arquitectura REST 6|
RESTRICCIONES: CLIENT-SERVER
Separación de responsabilidades.
Mejora la portabilidad a distintas plataformas.
Aumento de la escalabilidad.
Componentes evolucionan de forma
independiente.
Arquitectura REST
7. Arquitectura REST 7|
RESTRICCIONES: STATELESS
Cada petición contiene toda la información
necesaria para que el servidor la procese.
El estado de sesión se mantiene totalmente en el
cliente.
Componentes evolucionan de forma
independiente.
Arquitectura REST
8. Arquitectura REST 8|
RESTRICCIONES: CACHEABLE
Respuestas del servidor (representaciones)
son cacheables:
Implícita
Explicita
Negociables
Arquitectura REST
9. Arquitectura REST 9|
RESTRICCIONES: UNIFORM INTERFACE
Principal característica diferenciadora frente a
otras arquitecturas.
Las implementaciones se separan de los
servicios que proporcionan
¿Cómo?
Verbos HTTP
URIs (nombres de recursos)
Respuestas HTTP (status, body)
Arquitectura REST
10. Arquitectura REST 10|
RESTRICCIONES: LAYERED SYSTEM
Los servicios REST están orientados a la
escalabilidad.
El cliente no sabe si la petición se realiza
directamente a un servidor, un sistema de
cachés o por ejemplo un balanceador que se
encarga de redirigirlo hacia un servidor final.
Arquitectura REST
11. Arquitectura REST 11|
RESTRICCIONES: CODE-ON-DEMAND
Servidor puede extender o personalizar
temporalmente la funcionalidad del cliente.
Transferencia de la lógica al cliente.
Cliente ejecuta la lógica.
Restricción opcional
Ejemplos:
Java Applets
JavaScript
Arquitectura REST
14. Arquitectura REST 14|
LEVEL 0: THE SWAMP OF POX (PLAIN OLD XML)
Arquitectura REST
Una URI, un Método HTTP
HTTP como un sistema de transporte para
interacciones remotos
Basado en Remote Procedure Invocation.
XML-RPC y SOAP
15. Arquitectura REST 15|
LEVEL 1: RESOURCES
Arquitectura REST
URI (Uniform Resource Identifier)
Los nombres de URI no deben implicar una
acción
Evitar uso de verbos.
Deben ser Únicas
Independientes del formato.
Deben mantener una jerarquía lógica.
Los filtrados de información de un recurso no se
hacen en la URI.
18. Arquitectura REST 18|
LEVEL 2: HTTP VERBS
GET para obtener la representacion/es de un
recurso/s
POST para crear un recurso
PUT para modificar un recurso
DELETE para eliminar un recuerso
PATCH para actualizar parcialmente un recurso
Uso de HTTP Status Code para indicar el resultado:
HTTP/1.1 2xx Petición Correcta
HTTP/1.1 4xx Errores del Cliente
HTTP/1.1 5xx Errores en el Servidor
Arquitectura REST
20. Arquitectura REST 20|
LEVEL 3: HYPERMEDIA CONTROLS
Arquitectura REST
HATEOS (Hypermedia as the Engine of Application
State)
API debe poder ser navegable sin documentación
24. Arquitectura REST 24|
REST ANTI-PATTERS BY STEFAN TILKOV
Todas las peticiones a través de GET
Todas las peticiones mediante POST
Cache, ¿qué cache?????
No utilizar códigos de respuesta
Mal uso de cookies
Olvidarnos de Hypermedia
Haciendo caso omiso de los tipos MIME
Mal uso de las cabeceras HTTP
Arquitectura REST
25. Arquitectura REST 25|
SEGURIDAD
Arquitectura REST
Recordad que nuestros servicios web deben ser
stateless (sin estado):
No utilizar cookies o HTTP Session.
El cliente debe enviar las credenciales de
autenticación en cada llamada.
Opciones:
HTTP Security
OAuth
26. Arquitectura REST 26|
DOCUMENTACIÓN
Arquitectura REST
JavadocTagsForExtendedWADL
Permite añadir más información al WADL.
Se puede aplicar un transformada para generar
documentación ad hoc.
Swagger
Ampliamente extendido y estable.
Independiente del lenguaje de programación.
UI para probar los servicios.