SlideShare una empresa de Scribd logo
1 de 51
Descargar para leer sin conexión
Javier Vélez Reyes
@javiervelezreye
javier.velez.reyes@gmail.com
Madrid 30 Noviembre 2018
Modelos de API
Para El Diseño de
Servicios
Arquitectura de la Web
Un espacio de recursos accesibles de
forma única y con una variedad de
representaciones
Un sistema de información enlazado en
el que la generalidad y la portabilidad
fueran más importantes que las técnicas
gráficas sofisticadas y los extras
elaborados
Arquitectura de la Web
Tim Berners-Lee
Modelos de API Para El Diseño de Servicios
La Web de Tim Berners Lee
Cliente
Servidor
http://books.com/slot/452
http://books.com/slot/981
http://books.com/doctor/124
http://books.com/doctor/435
http://books.com/slot/765
Cliente - Servidor
Una arquitectura sencilla basada
en un esquema cliente servidor
Recursos
Una colección de recursos ya
sean estáticos o dinámicos
Identificadores
Una colección de identificadores
únicos para nombrar los recursos
Representaciones
Una colección de representaciones
para entregar cada uno de los
recursos
Modelos de API Para El Diseño de Servicios
La Web de Tim Berners Lee
XML | JSON
GET · POST · PUT · DEL
Cliente
Servidor
Solicitud - Respuesta
Un sencillo protocolo sin estado
para acceder a los recursos
Negociación
Enviar la colección de representaciones
admitidas para cada recurso
Acciones
4 tipos de acciones fijas para
operar con cada recurso
Modelos de API Para El Diseño de Servicios
La Web de Tim Berners Lee
Cliente
Servidor
http 1.1 200
Resource OK
http 1.1 203
Resource Created
http 1.1 500
Server Error
http 1.1 404
Resource Not Found
Resultado
Un código de Respuesta indicando el
resultado de la operación con el recurso
Mensaje
Un mensaje que contiene los datos de
respuesta para ser tratados por cliente
Metadatos
Información de cabecera que indica
persigue diferentes propósitos
La computación distribuida nos invita a
modelar negocios en un marco de
restricciones crecientes sobre la propia
arquitectura de la Web.
Computación Distribuida
Roy T. Fielding
Modelos de API Para El Diseño de Servicios
Diseño de Servicios
Componente
Modelo
Estado
Configuración
Reglas
Eventos
Business Logic Web Architecture
Links
Recursos
Acciones
Representaciones
Modelos Diseño
Restricciones
Modelos de API Para El Diseño de Servicios
Diseño de Servicios
Cómo se modelan las acciones
que ofrece del servicio
Cómo se modelan los datos
que recibe el servicio
A B
Cómo se modelan el estado
que atraviesa el servicio
SSolicitud
EEstado RRespuesta
AAcciones
Cómo se modelan los resultados
que recibe el servicio
Modelos de API Para El Diseño de Servicios
Principios de Diseño de Servicios
Contrato Uniforme
Una vez que un desarrollador se familiariza
con una de sus API, debería poder seguir el
enfoque similar para otras API
Cliente Servidor
GET·POST·PUT·DEL
Modelos de API Para El Diseño de Servicios
Principios de Diseño de Servicios
Arquitectura Cliente - Servidor
Tanto servidores como clientes deben poder
evolucionar independientemente siempre
que la interfaz entre ambos no cambie.
GET·POST·PUT·DEL
Cliente Servidor
Modelos de API Para El Diseño de Servicios
Principios de Diseño de Servicios
Diseño Sin Estado
El contexto de cliente entre solicitudes no
debe almacenarse en el servidor. El cliente
es responsable de gestionar su estado.
Cliente Servidor
In + State
Out + State
GET·POST·PUT·DEL
Modelos de API Para El Diseño de Servicios
Principios de Diseño de Servicios
Sistema de Cache
Los mecanismos de caché bien gestionados
eliminan solicitudes al servidor. Ello mejora
la escalabilidad y el rendimiento.
Servidor
GET·POST·PUT·DEL
Cliente
Modelos de API Para El Diseño de Servicios
Principios de Diseño de Servicios
Sistema de Capas
La arquitectura de servicio tras el contrato
uniforme resulta transparente para el cliente
del servicio.
Cliente Servidor
In + State
Out + State
GET·POST·PUT·DEL
Modelos de API Para El Diseño de Servicios
Recursos
Contrato
Mensaje
post
Actions
Data
State
/service
Acciones
C S
/service [POST] – {
action: 'check',
doctor: 'mjones',
date : '30/11/2018'
}
C S
/service [200] – [
{ id: 1, doctor: 'mjones' hour: '14:00' },
{ id: 2, doctor: 'mjones' hour: '16:50' },
{ id: 3, doctor: 'mjones' hour: '18:10' }
]
C S
/service [POST] – {
action : 'book',
doctor : 'mjones',
date : '30/11/2018'
id : 3
}
C S
/service [201]
Message Driven Comunication
Modelos de Comunicación
Modelos de API Para El Diseño de Servicios
post
Actions
Data
State
Entidades x Acciones
/doctors
/doctor
/patient
/slot
C S
/doctors/mjones [POST] – {
action: 'check',
date : '30/11/2018'
}
C S
/doctors/mjones [200] – [
{ id: 1, doctor: 'mjones' hour: '14:00' },
{ id: 2, doctor: 'mjones' hour: '16:50' },
{ id: 3, doctor: 'mjones' hour: '18:10' }
]
C S
/doctors/mjones [POST] – {
action : 'book',
date : '30/11/2018'
id : 3
} C S
/doctors/mjones [201]
Modelos de Comunicación
Recursos
Contrato
Mensaje
Resource Driven Comunication
Modelos de API Para El Diseño de Servicios
Data
State
get
post
put
del Entidades x Acciones
/doctors
/doctor
/patient
/slot
C S
/doctors/mjones [GET] – {
date: '30/11/2018'
}
C S
/doctors/mjones [200] – [
{ id: 1, doctor: 'mjones' hour: '14:00' },
{ id: 2, doctor: 'mjones' hour: '16:50' },
{ id: 3, doctor: 'mjones' hour: '18:10' }
]
C S
/doctors/mjones [POST] – {
date: '30/11/2018'
id : 3
}
C S
/doctors/mjones [201]
Modelos de Comunicación
Recursos
Contrato
Mensaje
Contract Driven Comunication
Modelos de API Para El Diseño de Servicios
get
post
put
del
Data
Estado x Acciones
/doctors
/doctor
/patient
/slot
C S
/service [GET]
C S
/service [200] – [
{ rel: 'doctors' link: '/service/123' },
{ rel: 'slots' link: '/service/458' }
]
C S
/service/123[GET]
C S
/service [200] – [
{ rel: 'mjones' link: '/service/234' },
{ rel: 'amiler' link: '/service/235' },
{ rel: 'ksmith' link: '/service/236' }
]
C S
/service/234[GET]
Modelos de Comunicación
Recursos
Contrato
Mensaje
Hypermedia Driven Comunication
Quiero distinguir entre servicios web
buenos y malos, y averiguar cuál es la
relación entre las restricciones de REST y
la calidad del servicio web.
Modelo de Madurez
Leonard Richardson
Modelos de API Para El Diseño de Servicios
Niveles de Madurez de Richardson
Post
/service
Acciones
Estado
Datos
/doctors
/slots
Get
Post
Put
Del
Datos
Estado
Nivel #0
Message Driven
Nivel #1
Resource Driven
Nivel #2
Contract Driven
Nivel #3
Hypermedia Driven
Restricciones
Flexibilidad
+
Descubrimiento
+
REST
Modelos de API Para El Diseño de Servicios
Niveles de Madurez de Richardson
Descubrimiento
Flexibilidad
RendimientoSimplicidad
Homogeneidad
Nivel #0
Message Driven
Modelos de API Para El Diseño de Servicios
Niveles de Madurez de Richardson
Descubrimiento
Flexibilidad
RendimientoSimplicidad
Homogeneidad
Nivel #0
Message Driven
Nivel #1
Resource Driven
Modelos de API Para El Diseño de Servicios
Niveles de Madurez de Richardson
Descubrimiento
Flexibilidad
RendimientoSimplicidad
Homogeneidad
Nivel #0
Message URI
Nivel #1
Resource HTTP
Nivel #2
Contract Driven
Modelos de API Para El Diseño de Servicios
Niveles de Madurez de Richardson
Descubrimiento
Flexibilidad
RendimientoSimplicidad
Homogeneidad
Nivel #0
Message Driven
Nivel #1
Resource Driven
Nivel #2
Contract Driven
Nivel #3
Hypermedia Driven
Diseño de Servicios
Basados en Modelos
El modelado de servicios debería
resolverse atendiendo a las necesidades
de dominio y después desplegarse sobre
un protocolo
Tim Berners-Lee
Thomas Erl
Arquitecturas de
Servicios
Es primordial ocultar la mayor cantidad
de detalles subyacentes en un contrato.
Al hacerlo se mantiene una relación
desacoplada entre servicios en
cualquier composición.
Modelos de API Para El Diseño de Servicios
Modelos de Servicio
Modelos de Comunicación
Diseño de Servicios Centrado en Dominio
Comandos
Transacciones
Lenguaje
Proceso
Protocolo
Modelo
Espacio
Mensaje
Stream
Nivel #0
Messages
Nivel #1
Resources
Nivel #2
Contracts
Nivel #3
Hypermedia
<
Diseño
Modelos de API Para El Diseño de Servicios
Model Driven API
Se pretende explorar un modelo de
información basado en entidades, tipos y
relaciones. El modelo es fijo y existen
operaciones de acceso y modificación.
Modelos de Contrato de Servicios
Diagrama
Collection Book Author
Terror SciFi
C S
/author/123/books/1 [GET] C S
/author/123/books/1 [200] – Ok {
title : 'Rest In Action',
pages : 317,
year : 2018
}
C S
/author/123/book/1/purchase [POST]
C S
/author/123/book/1/purchase [201] – Ok
Si el modelo de información es estable una
solución de nivel #2 resulta adecuada
Solución
Modelos de API Para El Diseño de Servicios
Space Driven API
Se pretende explorar un espacio de
información basado en entidades, tipos y
relaciones. El espacio es desconocido y
cambiante.
Modelos de Contrato de Servicios
Diagrama
C S
/bookstore/authors [GET] C S
/authors [200] – Ok [
{ rel: 'author', link: '/123' }
{ rel: 'author', link: '/456' }
{ rel: 'author', link: '/789' }
]
C S
/authors/123 [GET]
C S
/author/123/ [200] – {
rel: 'purchase'
link: '/123'
action: 'post'
}
Solución
Si el modelo de información es voluble una
solución de nivel #3 es mejor
Modelos de API Para El Diseño de Servicios
Modelos de Diseño de Servicios
Command Driven API
Un servicio acepta comandos y los ejecuta
de forma atómica. Los servicios no tienen
estado y se ejecutan de forma
bloqueante.
Diagrama
Cmd A
Entorno de Ejecución
Cmd B
Solución
Una solución de nivel #2 cierra el número
de comandos a un conjunto cerrado
C S
/commands/A [POST] – {
context : ...
}
Una solución de nivel #1 permite abrir el
conjunto de comandos bajo demanda
C S
/commands [POST] – {
command : 'A',
context : 'mjones',
}
Modelos de API Para El Diseño de Servicios
Transaction Driven API
Un servicio acepta comandos y los ejecuta
de forma transaccional. Existe operación
de apertura y cierre de sesión. Una sesión
abierta se puede revertir.
Modelos de Contrato de Servicios
Diagrama
open
Tr A
close
Solución
Una solución de nivel #3 permite gestionar
la sesión transaccional cómodamente
C S
/session [GET] C S
/session [201] - {
rel : 'session'
link : '/123'
action : 'get'
}C S
/session/123 [GET]
/session/123 [200] - {
rel: 'self' link: '/123' action: 'get'
rel: 'add' link: '/123' action: 'put'
rel: 'commit' link: '/123' action: 'post'
rel: 'revert' link: '/123' action: 'del'
}
C S
Modelos de API Para El Diseño de Servicios
Transaction Driven API
Un servicio acepta comandos y los ejecuta
de forma transaccional. Existe operación
de apertura y cierre de sesión. Una sesión
abierta se puede revertir.
Diagrama
Modelos de Contrato de Servicios
open
Tr A
close
C S
/session/123 [PUT] { ... }
/session/123 [PUT] { ... }
/session/123 [PUT] { ... }
C S/session/123 [200] - {
rel: 'self' link: '/123' action: 'get'
rel: 'add' link: '/123' action: 'put'
rel: 'commit' link: '/123' action: 'post'
rel: 'revert' link: '/123' action: 'del'
}
C S
/session/123 [POST] { ... }
C S
/session/123 [201] - OK
Solución
Una solución de nivel #3 permite gestionar
la sesión transaccional cómodamente
Modelos de API Para El Diseño de Servicios
Language Driven API
Un servicio acepta una expresión
sintáctica que es capaz de procesar en un
contexto de ejecución y devolver un
resultado.
Modelos de Contrato de Servicios
Diagrama
Exp A
Entorno de Ejecución
Exp B
C S
/engine [POST] – {
query : 'user(id: 1) {
name
age
friends { name }
}'
}
C S
/engine [200] - Ok
Una solución de nivel #2 resulta en un
contrato demasiado rígido para este caso
C S
/users/1 [GET]
/users/1/friends [GET]
Una solución de nivel #1 resulta lo mejor
para un servicio con modelo de lenguaje
Solución
Modelos de API Para El Diseño de Servicios
Process Driven API
Un servicio realiza un proceso de larga
duración. La gestión de estado debe ser
responsabilidad del cliente.
Modelos de Contrato de Servicios
Diagrama
A B C
C S
/process [GET] C S
/engine [200] – {
rel: 'A' link: '/132'
}
C S
/process/123 [GET] C S
/engine [200] – {
rel: 'B' link: '/234'
}
C S
/process/234[GET] C S
/engine [200] – {
rel: 'C' link: '/345'
}
Una solución de nivel #3 permite un modo
dialógico idóneo para avanzar un proceso
Solución
Modelos de API Para El Diseño de Servicios
Protocol Driven API
Un servicio coordina la actividad coopera-
tiva que se da entre dos agentes. Deben
mantenerse las propiedades de integridad
y vivacidad del protocolo.
Modelos de Contrato de Servicios
Diagrama
wait
Bid Ready
Price
C S
/auctions [GET] C S
/auctions [200] – [
{ rel: 'auction' link: '/123' }
{ rel: 'auction' link: '/456' }
{ rel: 'auction' link: '/789' }
]
C S
/auction/123 [GET]
C S
/auction/123 [200] – {
rel : 'bid'
link : '/123'
action : 'post'
schema : { amount: 'Integer' }
}
Una solución de nivel #3 permite un modo
dialógico idóneo para control de protocolos
Solución
Modelos de API Para El Diseño de Servicios
Protocol Driven API
Un servicio coordina la actividad coopera-
tiva que se da entre dos agentes. Deben
mantenerse las propiedades de integridad
y vivacidad del protocolo.
Diagrama
Modelos de Contrato de Servicios
wait
Bid Ready
Price
C S
/auction/123 [POST] – {
amount : 10
}
Una solución de nivel #3 permite un modo
dialógico idóneo para control de protocolos
C S
/auction/123 [200] – Ok {
rel : 'bid'
link : '/1231'
action : 'post'
schema : { amount: 'Integer' }
}
C S
/auction/1231 [POST] – {
amount : 10
}
C S
/engine [403] – Forbidden {
rel: 'A' link: '/1321'
}
Solución
Modelos de API Para El Diseño de Servicios
Modelos de Contrato de Servicios
Solución
Una solución de nivel #2 permite un modo
de asignación de buzones operativo
Message Driven API
Se pretende implementar un sistema de
mensajería para articular comunicación
entre cliente desacoplada espacial y
temporalmente.
Diagrama
A B C
Usuario A
Usuario B
to: B
from: A
C S
/mailbox/A [POST] – { ... }
C S
/mailbox [201] – Ok
C S
/mailbox/B [GET] – { ... }
C S
/mailbox [200] – [
{ id: 1, from: 'A', body: '...' }
{ id: 1, from: 'A', body: '...' }
{ id: 1, from: 'A', body: '...' }
]
Modelos de API Para El Diseño de Servicios
Stream Driven API
Se pretende dar soporte a un mecanismo
de comunicación asíncrono basado en
eventos. La consumición de los eventos es
independiente por cliente
Modelos de Contrato de Servicios
Solución
Una solución de nivel #2 permite un modo
de asignación de buzones operativo
Diagrama
A
B
C
Usuario C
Usuario A
topic: X
Usuario B
X
A
B
C
C S
/streams [201] – Ok
C S
/streams/user/B/topic/X [GET]
C S
/streams/user/B/topic/X [200] – { ... }
/streams/topic/X [POST] – { ... }
C S
Hacia una Arquitectura
Centrada en el Dominio
En el diseño de arquitecturas de servicio
deberíamos guiarnos por la abstracción
para crear soluciones desacopladas
Modelos de API Para El Diseño de Servicios
Diseño Centrado en el Contrato
Diseño
Abstracto
Bajo
Acoplamiento
Orientación a
Dominio
Dependencias
Inversión
Contrato
Estructura
Colaboración
Implementación
Tecnología
Protocolo
Mensaje
Estado
Red
Patrón
Modelo
Lenguaje
Catálogo
Contexto
Proceso
Modelos de API Para El Diseño de Servicios
Arquitectura de Servicios
Nivel de Cliente
Nivel de Servicio
Modelos de Comunicación
Modelos de Comunicación
Modelos de
Servicio
Modelos de
Cliente
Nivel de Protocolo
Modelos de API Para El Diseño de Servicios
Arquitectura de Servicios. Nivel de Protocolo
NiveldeServicio
Nivel 0Nivel 1Nivel 2Nivel 3
Enpoints Fijos
Acciones Fijas
Estado Libre
Enpoints Fijos
Estado Fijo
Enpoints Fijos
Acciones Libres
Estado Libre
Enpoint Estado
& Acciones
Libres
NiveldeCliente
Modelos de API Para El Diseño de Servicios
import Command from 'Commands'
@Command
class Account {
constructor () {}
@Process
execute(command) {}
}
Arquitectura de Servicios. Nivel de Servicio
Nivel de Servicio
NiveldeProtocolo
Modelos de API Para El Diseño de Servicios
import Command from 'Commands'
@Command
class Account {
constructor () {}
@Process
execute(command) {}
}
Arquitectura de Servicios. Nivel de Servicio
Nivel de Servicio
import Session from 'Transactions'
@Session
class Account {
constructor () {}
@Open create () {}
@Task task (task) {}
@Commit commit () {}
@Revert revert () {}
@Close end () {}
}
NiveldeProtocolo
Modelos de API Para El Diseño de Servicios
import Command from 'Commands'
@Command
class Account {
constructor () {}
@Process
execute(command) {}
}
Arquitectura de Servicios. Nivel de Servicio
Nivel de Servicio
import Session from 'Transactions'
@Session
class Account {
constructor () {}
@Open create () {}
@Task task (task) {}
@Commit commit () {}
@Revert revert () {}
@Close end () {}
}
import Protocol from 'Protocols'
@Protocol
class Auction {
constructor () {}
@State init (ctx) { return ctx }
@State ready (ctx) { return ctx }
@State wait (ctx) { return ctx }
@State end (ctx) { return ctx }
}
NiveldeProtocolo
Modelos de API Para El Diseño de Servicios
Arquitectura de Servicios. Nivel de Protocolo
NiveldeServicio
Nivel 0Nivel 1Nivel 2Nivel 3
Enpoints Fijos
Acciones Fijas
Estado Libre
Enpoints Fijos
Estado Fijo
Enpoints Fijos
Acciones Libres
Estado Libre
Enpoint Estado
& Acciones
Libres
NiveldeCliente
Modelos de API Para El Diseño de Servicios
wc-view wc-command
wc-context
<wc-view id="A"/>
<wc-view id="B"/>
<wc-context id="C">
<wc-rule ref="A" on="tap"/>
<wc-rule ref="B" on="tap"/>
</wc-context>
<wc-commands context="#C">
<wc-view ref="#A:tap"/>
<wc-view ref="#B:tap"/>
<wc-command key="cmd.X"/>
<wc-command key="cmdY"/>
</wc-commands>
Arquitectura de Servicios. Nivel de Servicio
NiveldeProtocolo
Nivel de Cliente
Modelos de API Para El Diseño de Servicios
Arquitectura de Servicios. Nivel de Servicio
wc-view wc-session
wc-task-factory
<wc-view id="A"/>
<wc-taks ref="A">
<wc-task key="Tx" on="add"/>
<wc-task key="Ty" on="drop"/>
</wc-tasks>
<wc-session ref="#A">
<wc-rule on="purchase" do="commit"/>
<wc-rule on="discard" do="revert"/>
</wc-commands>
NiveldeProtocolo
Nivel de Cliente
Modelos de API Para El Diseño de Servicios
NiveldeProtocolo
Arquitectura de Servicios. Nivel de Servicio
wc-view wc-controller
<wc-view id="A"/>
<wc-controller ref="#A #B">
<wc-rule when="init" disabled/>
<wc-rule when="wait" disabled/>
<wc-rule when="ready" enabled/>
<wc-rule when="end" disabled/>
</wc-controller>
<wc-view id="B"/>
Nivel de Cliente
Modelos de API Para El Diseño de Servicios
Modelos de Servicio
Dirigir los esfuerzos de diseño de
Servicios de acuerdo a modelos de
dominio conduce a arquitecturas
más flexibles y Adaptativas
Javier Vélez Reyes
@javiervelezreye
javier.velez.reyes@gmail.com
Madrid 30 Noviembre 2018
Modelos de API
Para El Diseño de
Servicios

Más contenido relacionado

La actualidad más candente

Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)Micael Gallego
 
Herramientas CASE
Herramientas CASEHerramientas CASE
Herramientas CASEI R
 
Prototipos
PrototiposPrototipos
PrototiposTensor
 
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...José Antonio Sandoval Acosta
 
Ejemplos de diagramas =)
Ejemplos de diagramas =)Ejemplos de diagramas =)
Ejemplos de diagramas =)bat1820
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clasesRamiro Estigarribia Canese
 
Modelo vista controlador
Modelo vista controladorModelo vista controlador
Modelo vista controladorEmilio Sarabia
 
Actividad #3 cliente servidor
Actividad #3 cliente servidorActividad #3 cliente servidor
Actividad #3 cliente servidorRobertNicolas8
 
12 Steps to API Load Testing with Apache JMeter
12 Steps to API Load Testing with Apache JMeter12 Steps to API Load Testing with Apache JMeter
12 Steps to API Load Testing with Apache JMeterWSO2
 
DISEÑO DE BASES DE DATOS DISTRIBUIDAS
DISEÑO DE BASES DE DATOS DISTRIBUIDASDISEÑO DE BASES DE DATOS DISTRIBUIDAS
DISEÑO DE BASES DE DATOS DISTRIBUIDASNatalia Ludeña
 
Requerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no FuncionalesRequerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no Funcionalessullinsan
 
Requerimientos de un Sistema (usando criterios del swebok)
Requerimientos de un Sistema (usando criterios del swebok)Requerimientos de un Sistema (usando criterios del swebok)
Requerimientos de un Sistema (usando criterios del swebok)Miguel Miranda
 
Designing applications with web access capabilities
Designing applications with web access capabilitiesDesigning applications with web access capabilities
Designing applications with web access capabilitiesK Senthil Kumar
 

La actualidad más candente (20)

analisis de aplicaciones web
analisis de aplicaciones webanalisis de aplicaciones web
analisis de aplicaciones web
 
Infografia de ing. de requisitos y requerimiento
Infografia de ing. de requisitos y requerimientoInfografia de ing. de requisitos y requerimiento
Infografia de ing. de requisitos y requerimiento
 
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
 
Herramientas CASE
Herramientas CASEHerramientas CASE
Herramientas CASE
 
Prototipos
PrototiposPrototipos
Prototipos
 
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
 
Ejemplos de diagramas =)
Ejemplos de diagramas =)Ejemplos de diagramas =)
Ejemplos de diagramas =)
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clases
 
Ejercicios uml
Ejercicios umlEjercicios uml
Ejercicios uml
 
Accesibilidad Web
Accesibilidad WebAccesibilidad Web
Accesibilidad Web
 
Modelo vista controlador
Modelo vista controladorModelo vista controlador
Modelo vista controlador
 
Introduction to Web Services
Introduction to Web ServicesIntroduction to Web Services
Introduction to Web Services
 
Actividad #3 cliente servidor
Actividad #3 cliente servidorActividad #3 cliente servidor
Actividad #3 cliente servidor
 
12 Steps to API Load Testing with Apache JMeter
12 Steps to API Load Testing with Apache JMeter12 Steps to API Load Testing with Apache JMeter
12 Steps to API Load Testing with Apache JMeter
 
Aplicaciones distribuidas
Aplicaciones distribuidasAplicaciones distribuidas
Aplicaciones distribuidas
 
Json short manual
Json short manualJson short manual
Json short manual
 
DISEÑO DE BASES DE DATOS DISTRIBUIDAS
DISEÑO DE BASES DE DATOS DISTRIBUIDASDISEÑO DE BASES DE DATOS DISTRIBUIDAS
DISEÑO DE BASES DE DATOS DISTRIBUIDAS
 
Requerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no FuncionalesRequerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no Funcionales
 
Requerimientos de un Sistema (usando criterios del swebok)
Requerimientos de un Sistema (usando criterios del swebok)Requerimientos de un Sistema (usando criterios del swebok)
Requerimientos de un Sistema (usando criterios del swebok)
 
Designing applications with web access capabilities
Designing applications with web access capabilitiesDesigning applications with web access capabilities
Designing applications with web access capabilities
 

Similar a Modelos de API Para El Diseño de Servicios

Arquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptx
Arquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptxArquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptx
Arquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptxXavierNavia
 
Exprimiendo SharePoint 2010
Exprimiendo SharePoint 2010Exprimiendo SharePoint 2010
Exprimiendo SharePoint 2010Juan Pablo
 
144 Rest Web Services
144 Rest Web Services144 Rest Web Services
144 Rest Web ServicesGeneXus
 
Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...
Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...
Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...Samhya LLerena
 
Novedades en Desarrollo en SharePoint 2013
Novedades en Desarrollo en SharePoint 2013Novedades en Desarrollo en SharePoint 2013
Novedades en Desarrollo en SharePoint 2013Juan Carlos Gonzalez
 
Presentacion Connected Systems
Presentacion Connected SystemsPresentacion Connected Systems
Presentacion Connected Systemsrolosandoval
 
Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010
Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010
Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010Andrés Iturralde
 
Integración de Tecnologías y Plataformas.pptx
Integración de Tecnologías y Plataformas.pptxIntegración de Tecnologías y Plataformas.pptx
Integración de Tecnologías y Plataformas.pptxLuisTenorio42
 
Aplicaciones web - Gonzalo Acte
Aplicaciones web - Gonzalo ActeAplicaciones web - Gonzalo Acte
Aplicaciones web - Gonzalo Acte2008PA2Info3
 
10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...
10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...
10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...Luis Fernando Aguas Bucheli
 
Sharepoint server 2010 - La nueva colaboración
Sharepoint server 2010  - La nueva colaboraciónSharepoint server 2010  - La nueva colaboración
Sharepoint server 2010 - La nueva colaboraciónAndrés Iturralde
 
Actividad 3 german orlando tinjaca
Actividad 3 german orlando tinjacaActividad 3 german orlando tinjaca
Actividad 3 german orlando tinjacaGermanOrlandoTinjaca
 
SharePoint 2010 Introducción para Desarrolladores
SharePoint 2010 Introducción para DesarrolladoresSharePoint 2010 Introducción para Desarrolladores
SharePoint 2010 Introducción para DesarrolladoresAndrés Iturralde
 
Sistemas cliente servidor
Sistemas cliente   servidorSistemas cliente   servidor
Sistemas cliente servidorJramos_95
 
Novedades en BCS en SharePoint 2013
Novedades en BCS en SharePoint 2013Novedades en BCS en SharePoint 2013
Novedades en BCS en SharePoint 2013Juan Carlos Gonzalez
 
Fundamentos para el diseño de una RESTful API pragmática
Fundamentos para el diseño de una RESTful API pragmáticaFundamentos para el diseño de una RESTful API pragmática
Fundamentos para el diseño de una RESTful API pragmáticaLeoWong91
 
Tarea1 cliente servidor1_buenaventura_jarrison
Tarea1 cliente servidor1_buenaventura_jarrisonTarea1 cliente servidor1_buenaventura_jarrison
Tarea1 cliente servidor1_buenaventura_jarrisonJarrison Buenaventura
 

Similar a Modelos de API Para El Diseño de Servicios (20)

Arquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptx
Arquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptxArquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptx
Arquitectura-orientada-a-Servicios.-v-2017.01-Prof.-L.-Straccia.pptx
 
Exprimiendo SharePoint 2010
Exprimiendo SharePoint 2010Exprimiendo SharePoint 2010
Exprimiendo SharePoint 2010
 
144 Rest Web Services
144 Rest Web Services144 Rest Web Services
144 Rest Web Services
 
Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...
Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...
Importancia de los Sistemas Cliente Servidor, su arquitectura y describir sus...
 
Novedades en Desarrollo en SharePoint 2013
Novedades en Desarrollo en SharePoint 2013Novedades en Desarrollo en SharePoint 2013
Novedades en Desarrollo en SharePoint 2013
 
Clases 30 05
Clases 30 05Clases 30 05
Clases 30 05
 
Presentacion Connected Systems
Presentacion Connected SystemsPresentacion Connected Systems
Presentacion Connected Systems
 
Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010
Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010
Bajo el Toldo con la Programabilidad de Microsoft SharePoint 2010
 
Arquitectura de Software
Arquitectura de SoftwareArquitectura de Software
Arquitectura de Software
 
Integración de Tecnologías y Plataformas.pptx
Integración de Tecnologías y Plataformas.pptxIntegración de Tecnologías y Plataformas.pptx
Integración de Tecnologías y Plataformas.pptx
 
Aplicaciones web - Gonzalo Acte
Aplicaciones web - Gonzalo ActeAplicaciones web - Gonzalo Acte
Aplicaciones web - Gonzalo Acte
 
Arquitectura cliente
Arquitectura cliente Arquitectura cliente
Arquitectura cliente
 
10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...
10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...
10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Caracterís...
 
Sharepoint server 2010 - La nueva colaboración
Sharepoint server 2010  - La nueva colaboraciónSharepoint server 2010  - La nueva colaboración
Sharepoint server 2010 - La nueva colaboración
 
Actividad 3 german orlando tinjaca
Actividad 3 german orlando tinjacaActividad 3 german orlando tinjaca
Actividad 3 german orlando tinjaca
 
SharePoint 2010 Introducción para Desarrolladores
SharePoint 2010 Introducción para DesarrolladoresSharePoint 2010 Introducción para Desarrolladores
SharePoint 2010 Introducción para Desarrolladores
 
Sistemas cliente servidor
Sistemas cliente   servidorSistemas cliente   servidor
Sistemas cliente servidor
 
Novedades en BCS en SharePoint 2013
Novedades en BCS en SharePoint 2013Novedades en BCS en SharePoint 2013
Novedades en BCS en SharePoint 2013
 
Fundamentos para el diseño de una RESTful API pragmática
Fundamentos para el diseño de una RESTful API pragmáticaFundamentos para el diseño de una RESTful API pragmática
Fundamentos para el diseño de una RESTful API pragmática
 
Tarea1 cliente servidor1_buenaventura_jarrison
Tarea1 cliente servidor1_buenaventura_jarrisonTarea1 cliente servidor1_buenaventura_jarrison
Tarea1 cliente servidor1_buenaventura_jarrison
 

Más de Javier Vélez Reyes

Arquitecturas Dirigidas por la Experiencia
Arquitecturas Dirigidas por la ExperienciaArquitecturas Dirigidas por la Experiencia
Arquitecturas Dirigidas por la ExperienciaJavier Vélez Reyes
 
Arquitecturas Adaptativas de Componentes Web
Arquitecturas Adaptativas de Componentes WebArquitecturas Adaptativas de Componentes Web
Arquitecturas Adaptativas de Componentes WebJavier Vélez Reyes
 
El futuro es hoy. Del Nomadismo al Capitalismo Web
El futuro es hoy. Del Nomadismo al Capitalismo WebEl futuro es hoy. Del Nomadismo al Capitalismo Web
El futuro es hoy. Del Nomadismo al Capitalismo WebJavier Vélez Reyes
 
Estrategias de Programación & Estructuras de Datos
Estrategias de Programación & Estructuras de DatosEstrategias de Programación & Estructuras de Datos
Estrategias de Programación & Estructuras de DatosJavier Vélez Reyes
 
Arquitectura de Componentes Web. Patrones de Acceso a Datos
Arquitectura de Componentes Web. Patrones de Acceso a DatosArquitectura de Componentes Web. Patrones de Acceso a Datos
Arquitectura de Componentes Web. Patrones de Acceso a DatosJavier Vélez Reyes
 
Arquitecturas de Componentes Web. Patrones de Composición
Arquitecturas de Componentes Web. Patrones de ComposiciónArquitecturas de Componentes Web. Patrones de Composición
Arquitecturas de Componentes Web. Patrones de ComposiciónJavier Vélez Reyes
 
Arquitecturas Para La Reutilización en JavaScript
Arquitecturas Para La Reutilización en JavaScriptArquitecturas Para La Reutilización en JavaScript
Arquitecturas Para La Reutilización en JavaScriptJavier Vélez Reyes
 
Taller de Programación Funcional en JavaScript
Taller de Programación Funcional en JavaScriptTaller de Programación Funcional en JavaScript
Taller de Programación Funcional en JavaScriptJavier Vélez Reyes
 
Metaprogramación Compositiva en JavaScript
Metaprogramación Compositiva en JavaScriptMetaprogramación Compositiva en JavaScript
Metaprogramación Compositiva en JavaScriptJavier Vélez Reyes
 
Principios de Diseño de Componentes Web
Principios de Diseño de Componentes WebPrincipios de Diseño de Componentes Web
Principios de Diseño de Componentes WebJavier Vélez Reyes
 
Arquitecturas Reactivas de Streams
Arquitecturas Reactivas de StreamsArquitecturas Reactivas de Streams
Arquitecturas Reactivas de StreamsJavier Vélez Reyes
 
Programación Funcional en JavaScript
Programación Funcional en JavaScriptProgramación Funcional en JavaScript
Programación Funcional en JavaScriptJavier Vélez Reyes
 
Componentes Web y El Framework Polymer
Componentes Web y El Framework PolymerComponentes Web y El Framework Polymer
Componentes Web y El Framework PolymerJavier Vélez Reyes
 
Programación Asíncrona en Node JS
Programación Asíncrona en Node JSProgramación Asíncrona en Node JS
Programación Asíncrona en Node JSJavier Vélez Reyes
 

Más de Javier Vélez Reyes (19)

Arquitecturas Dirigidas por la Experiencia
Arquitecturas Dirigidas por la ExperienciaArquitecturas Dirigidas por la Experiencia
Arquitecturas Dirigidas por la Experiencia
 
Arquitecturas Adaptativas de Componentes Web
Arquitecturas Adaptativas de Componentes WebArquitecturas Adaptativas de Componentes Web
Arquitecturas Adaptativas de Componentes Web
 
El futuro es hoy. Del Nomadismo al Capitalismo Web
El futuro es hoy. Del Nomadismo al Capitalismo WebEl futuro es hoy. Del Nomadismo al Capitalismo Web
El futuro es hoy. Del Nomadismo al Capitalismo Web
 
Procesadores de Lenguajes II
Procesadores de Lenguajes IIProcesadores de Lenguajes II
Procesadores de Lenguajes II
 
Procesadores de Lenguajes I
Procesadores de Lenguajes IProcesadores de Lenguajes I
Procesadores de Lenguajes I
 
Estrategias de Programación & Estructuras de Datos
Estrategias de Programación & Estructuras de DatosEstrategias de Programación & Estructuras de Datos
Estrategias de Programación & Estructuras de Datos
 
Arquitectura de Componentes Web. Patrones de Acceso a Datos
Arquitectura de Componentes Web. Patrones de Acceso a DatosArquitectura de Componentes Web. Patrones de Acceso a Datos
Arquitectura de Componentes Web. Patrones de Acceso a Datos
 
Arquitecturas de Componentes Web. Patrones de Composición
Arquitecturas de Componentes Web. Patrones de ComposiciónArquitecturas de Componentes Web. Patrones de Composición
Arquitecturas de Componentes Web. Patrones de Composición
 
Arquitecturas Para La Reutilización en JavaScript
Arquitecturas Para La Reutilización en JavaScriptArquitecturas Para La Reutilización en JavaScript
Arquitecturas Para La Reutilización en JavaScript
 
Taller de Programación Funcional en JavaScript
Taller de Programación Funcional en JavaScriptTaller de Programación Funcional en JavaScript
Taller de Programación Funcional en JavaScript
 
El Proyecto Polymer
El Proyecto PolymerEl Proyecto Polymer
El Proyecto Polymer
 
Metaprogramación en JavaScript
Metaprogramación en JavaScriptMetaprogramación en JavaScript
Metaprogramación en JavaScript
 
La Web Orientada a Componentes
La Web Orientada a ComponentesLa Web Orientada a Componentes
La Web Orientada a Componentes
 
Metaprogramación Compositiva en JavaScript
Metaprogramación Compositiva en JavaScriptMetaprogramación Compositiva en JavaScript
Metaprogramación Compositiva en JavaScript
 
Principios de Diseño de Componentes Web
Principios de Diseño de Componentes WebPrincipios de Diseño de Componentes Web
Principios de Diseño de Componentes Web
 
Arquitecturas Reactivas de Streams
Arquitecturas Reactivas de StreamsArquitecturas Reactivas de Streams
Arquitecturas Reactivas de Streams
 
Programación Funcional en JavaScript
Programación Funcional en JavaScriptProgramación Funcional en JavaScript
Programación Funcional en JavaScript
 
Componentes Web y El Framework Polymer
Componentes Web y El Framework PolymerComponentes Web y El Framework Polymer
Componentes Web y El Framework Polymer
 
Programación Asíncrona en Node JS
Programación Asíncrona en Node JSProgramación Asíncrona en Node JS
Programación Asíncrona en Node JS
 

Último

El necesario mal del Legacy Code (Drupal Iberia 2024)
El necesario mal del Legacy Code (Drupal Iberia 2024)El necesario mal del Legacy Code (Drupal Iberia 2024)
El necesario mal del Legacy Code (Drupal Iberia 2024)Samuel Solís Fuentes
 
contabilidad para la inflacion, contabilidad superior
contabilidad para la inflacion, contabilidad superiorcontabilidad para la inflacion, contabilidad superior
contabilidad para la inflacion, contabilidad superiorDalia Rodriguez
 
serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...
serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...
serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...juanforero141
 
Tipos de datos en Microsoft Access definiciones.pdf
Tipos de datos en Microsoft Access definiciones.pdfTipos de datos en Microsoft Access definiciones.pdf
Tipos de datos en Microsoft Access definiciones.pdfCarlosSanchez452245
 
Especificación casos de uso del negocio
Especificación  casos de uso del negocioEspecificación  casos de uso del negocio
Especificación casos de uso del negocioMagemyl Egana
 
TECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdf
TECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdfTECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdf
TECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdfUPSE
 
Modelado de Casos de uso del negocio
Modelado de  Casos  de  uso  del negocioModelado de  Casos  de  uso  del negocio
Modelado de Casos de uso del negocioMagemyl Egana
 
TECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptx
TECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptxTECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptx
TECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptxUPSE
 

Último (8)

El necesario mal del Legacy Code (Drupal Iberia 2024)
El necesario mal del Legacy Code (Drupal Iberia 2024)El necesario mal del Legacy Code (Drupal Iberia 2024)
El necesario mal del Legacy Code (Drupal Iberia 2024)
 
contabilidad para la inflacion, contabilidad superior
contabilidad para la inflacion, contabilidad superiorcontabilidad para la inflacion, contabilidad superior
contabilidad para la inflacion, contabilidad superior
 
serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...
serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...
serenidad APP presentacion.pdfes una innovadora aplicación móvil diseñada par...
 
Tipos de datos en Microsoft Access definiciones.pdf
Tipos de datos en Microsoft Access definiciones.pdfTipos de datos en Microsoft Access definiciones.pdf
Tipos de datos en Microsoft Access definiciones.pdf
 
Especificación casos de uso del negocio
Especificación  casos de uso del negocioEspecificación  casos de uso del negocio
Especificación casos de uso del negocio
 
TECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdf
TECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdfTECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdf
TECNOLOGÍA DE LA INFORMACIÓN SLIDESHARE INVESTIGACION.pdf
 
Modelado de Casos de uso del negocio
Modelado de  Casos  de  uso  del negocioModelado de  Casos  de  uso  del negocio
Modelado de Casos de uso del negocio
 
TECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptx
TECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptxTECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptx
TECNOLOGIA DE LA INFORMACION Y MULTIMEDIA 15 MAYO.pptx
 

Modelos de API Para El Diseño de Servicios

  • 1. Javier Vélez Reyes @javiervelezreye javier.velez.reyes@gmail.com Madrid 30 Noviembre 2018 Modelos de API Para El Diseño de Servicios
  • 2. Arquitectura de la Web Un espacio de recursos accesibles de forma única y con una variedad de representaciones
  • 3. Un sistema de información enlazado en el que la generalidad y la portabilidad fueran más importantes que las técnicas gráficas sofisticadas y los extras elaborados Arquitectura de la Web Tim Berners-Lee
  • 4. Modelos de API Para El Diseño de Servicios La Web de Tim Berners Lee Cliente Servidor http://books.com/slot/452 http://books.com/slot/981 http://books.com/doctor/124 http://books.com/doctor/435 http://books.com/slot/765 Cliente - Servidor Una arquitectura sencilla basada en un esquema cliente servidor Recursos Una colección de recursos ya sean estáticos o dinámicos Identificadores Una colección de identificadores únicos para nombrar los recursos Representaciones Una colección de representaciones para entregar cada uno de los recursos
  • 5. Modelos de API Para El Diseño de Servicios La Web de Tim Berners Lee XML | JSON GET · POST · PUT · DEL Cliente Servidor Solicitud - Respuesta Un sencillo protocolo sin estado para acceder a los recursos Negociación Enviar la colección de representaciones admitidas para cada recurso Acciones 4 tipos de acciones fijas para operar con cada recurso
  • 6. Modelos de API Para El Diseño de Servicios La Web de Tim Berners Lee Cliente Servidor http 1.1 200 Resource OK http 1.1 203 Resource Created http 1.1 500 Server Error http 1.1 404 Resource Not Found Resultado Un código de Respuesta indicando el resultado de la operación con el recurso Mensaje Un mensaje que contiene los datos de respuesta para ser tratados por cliente Metadatos Información de cabecera que indica persigue diferentes propósitos
  • 7. La computación distribuida nos invita a modelar negocios en un marco de restricciones crecientes sobre la propia arquitectura de la Web. Computación Distribuida Roy T. Fielding
  • 8. Modelos de API Para El Diseño de Servicios Diseño de Servicios Componente Modelo Estado Configuración Reglas Eventos Business Logic Web Architecture Links Recursos Acciones Representaciones Modelos Diseño Restricciones
  • 9. Modelos de API Para El Diseño de Servicios Diseño de Servicios Cómo se modelan las acciones que ofrece del servicio Cómo se modelan los datos que recibe el servicio A B Cómo se modelan el estado que atraviesa el servicio SSolicitud EEstado RRespuesta AAcciones Cómo se modelan los resultados que recibe el servicio
  • 10. Modelos de API Para El Diseño de Servicios Principios de Diseño de Servicios Contrato Uniforme Una vez que un desarrollador se familiariza con una de sus API, debería poder seguir el enfoque similar para otras API Cliente Servidor GET·POST·PUT·DEL
  • 11. Modelos de API Para El Diseño de Servicios Principios de Diseño de Servicios Arquitectura Cliente - Servidor Tanto servidores como clientes deben poder evolucionar independientemente siempre que la interfaz entre ambos no cambie. GET·POST·PUT·DEL Cliente Servidor
  • 12. Modelos de API Para El Diseño de Servicios Principios de Diseño de Servicios Diseño Sin Estado El contexto de cliente entre solicitudes no debe almacenarse en el servidor. El cliente es responsable de gestionar su estado. Cliente Servidor In + State Out + State GET·POST·PUT·DEL
  • 13. Modelos de API Para El Diseño de Servicios Principios de Diseño de Servicios Sistema de Cache Los mecanismos de caché bien gestionados eliminan solicitudes al servidor. Ello mejora la escalabilidad y el rendimiento. Servidor GET·POST·PUT·DEL Cliente
  • 14. Modelos de API Para El Diseño de Servicios Principios de Diseño de Servicios Sistema de Capas La arquitectura de servicio tras el contrato uniforme resulta transparente para el cliente del servicio. Cliente Servidor In + State Out + State GET·POST·PUT·DEL
  • 15. Modelos de API Para El Diseño de Servicios Recursos Contrato Mensaje post Actions Data State /service Acciones C S /service [POST] – { action: 'check', doctor: 'mjones', date : '30/11/2018' } C S /service [200] – [ { id: 1, doctor: 'mjones' hour: '14:00' }, { id: 2, doctor: 'mjones' hour: '16:50' }, { id: 3, doctor: 'mjones' hour: '18:10' } ] C S /service [POST] – { action : 'book', doctor : 'mjones', date : '30/11/2018' id : 3 } C S /service [201] Message Driven Comunication Modelos de Comunicación
  • 16. Modelos de API Para El Diseño de Servicios post Actions Data State Entidades x Acciones /doctors /doctor /patient /slot C S /doctors/mjones [POST] – { action: 'check', date : '30/11/2018' } C S /doctors/mjones [200] – [ { id: 1, doctor: 'mjones' hour: '14:00' }, { id: 2, doctor: 'mjones' hour: '16:50' }, { id: 3, doctor: 'mjones' hour: '18:10' } ] C S /doctors/mjones [POST] – { action : 'book', date : '30/11/2018' id : 3 } C S /doctors/mjones [201] Modelos de Comunicación Recursos Contrato Mensaje Resource Driven Comunication
  • 17. Modelos de API Para El Diseño de Servicios Data State get post put del Entidades x Acciones /doctors /doctor /patient /slot C S /doctors/mjones [GET] – { date: '30/11/2018' } C S /doctors/mjones [200] – [ { id: 1, doctor: 'mjones' hour: '14:00' }, { id: 2, doctor: 'mjones' hour: '16:50' }, { id: 3, doctor: 'mjones' hour: '18:10' } ] C S /doctors/mjones [POST] – { date: '30/11/2018' id : 3 } C S /doctors/mjones [201] Modelos de Comunicación Recursos Contrato Mensaje Contract Driven Comunication
  • 18. Modelos de API Para El Diseño de Servicios get post put del Data Estado x Acciones /doctors /doctor /patient /slot C S /service [GET] C S /service [200] – [ { rel: 'doctors' link: '/service/123' }, { rel: 'slots' link: '/service/458' } ] C S /service/123[GET] C S /service [200] – [ { rel: 'mjones' link: '/service/234' }, { rel: 'amiler' link: '/service/235' }, { rel: 'ksmith' link: '/service/236' } ] C S /service/234[GET] Modelos de Comunicación Recursos Contrato Mensaje Hypermedia Driven Comunication
  • 19. Quiero distinguir entre servicios web buenos y malos, y averiguar cuál es la relación entre las restricciones de REST y la calidad del servicio web. Modelo de Madurez Leonard Richardson
  • 20. Modelos de API Para El Diseño de Servicios Niveles de Madurez de Richardson Post /service Acciones Estado Datos /doctors /slots Get Post Put Del Datos Estado Nivel #0 Message Driven Nivel #1 Resource Driven Nivel #2 Contract Driven Nivel #3 Hypermedia Driven Restricciones Flexibilidad + Descubrimiento + REST
  • 21. Modelos de API Para El Diseño de Servicios Niveles de Madurez de Richardson Descubrimiento Flexibilidad RendimientoSimplicidad Homogeneidad Nivel #0 Message Driven
  • 22. Modelos de API Para El Diseño de Servicios Niveles de Madurez de Richardson Descubrimiento Flexibilidad RendimientoSimplicidad Homogeneidad Nivel #0 Message Driven Nivel #1 Resource Driven
  • 23. Modelos de API Para El Diseño de Servicios Niveles de Madurez de Richardson Descubrimiento Flexibilidad RendimientoSimplicidad Homogeneidad Nivel #0 Message URI Nivel #1 Resource HTTP Nivel #2 Contract Driven
  • 24. Modelos de API Para El Diseño de Servicios Niveles de Madurez de Richardson Descubrimiento Flexibilidad RendimientoSimplicidad Homogeneidad Nivel #0 Message Driven Nivel #1 Resource Driven Nivel #2 Contract Driven Nivel #3 Hypermedia Driven
  • 25. Diseño de Servicios Basados en Modelos El modelado de servicios debería resolverse atendiendo a las necesidades de dominio y después desplegarse sobre un protocolo
  • 26. Tim Berners-Lee Thomas Erl Arquitecturas de Servicios Es primordial ocultar la mayor cantidad de detalles subyacentes en un contrato. Al hacerlo se mantiene una relación desacoplada entre servicios en cualquier composición.
  • 27. Modelos de API Para El Diseño de Servicios Modelos de Servicio Modelos de Comunicación Diseño de Servicios Centrado en Dominio Comandos Transacciones Lenguaje Proceso Protocolo Modelo Espacio Mensaje Stream Nivel #0 Messages Nivel #1 Resources Nivel #2 Contracts Nivel #3 Hypermedia < Diseño
  • 28. Modelos de API Para El Diseño de Servicios Model Driven API Se pretende explorar un modelo de información basado en entidades, tipos y relaciones. El modelo es fijo y existen operaciones de acceso y modificación. Modelos de Contrato de Servicios Diagrama Collection Book Author Terror SciFi C S /author/123/books/1 [GET] C S /author/123/books/1 [200] – Ok { title : 'Rest In Action', pages : 317, year : 2018 } C S /author/123/book/1/purchase [POST] C S /author/123/book/1/purchase [201] – Ok Si el modelo de información es estable una solución de nivel #2 resulta adecuada Solución
  • 29. Modelos de API Para El Diseño de Servicios Space Driven API Se pretende explorar un espacio de información basado en entidades, tipos y relaciones. El espacio es desconocido y cambiante. Modelos de Contrato de Servicios Diagrama C S /bookstore/authors [GET] C S /authors [200] – Ok [ { rel: 'author', link: '/123' } { rel: 'author', link: '/456' } { rel: 'author', link: '/789' } ] C S /authors/123 [GET] C S /author/123/ [200] – { rel: 'purchase' link: '/123' action: 'post' } Solución Si el modelo de información es voluble una solución de nivel #3 es mejor
  • 30. Modelos de API Para El Diseño de Servicios Modelos de Diseño de Servicios Command Driven API Un servicio acepta comandos y los ejecuta de forma atómica. Los servicios no tienen estado y se ejecutan de forma bloqueante. Diagrama Cmd A Entorno de Ejecución Cmd B Solución Una solución de nivel #2 cierra el número de comandos a un conjunto cerrado C S /commands/A [POST] – { context : ... } Una solución de nivel #1 permite abrir el conjunto de comandos bajo demanda C S /commands [POST] – { command : 'A', context : 'mjones', }
  • 31. Modelos de API Para El Diseño de Servicios Transaction Driven API Un servicio acepta comandos y los ejecuta de forma transaccional. Existe operación de apertura y cierre de sesión. Una sesión abierta se puede revertir. Modelos de Contrato de Servicios Diagrama open Tr A close Solución Una solución de nivel #3 permite gestionar la sesión transaccional cómodamente C S /session [GET] C S /session [201] - { rel : 'session' link : '/123' action : 'get' }C S /session/123 [GET] /session/123 [200] - { rel: 'self' link: '/123' action: 'get' rel: 'add' link: '/123' action: 'put' rel: 'commit' link: '/123' action: 'post' rel: 'revert' link: '/123' action: 'del' } C S
  • 32. Modelos de API Para El Diseño de Servicios Transaction Driven API Un servicio acepta comandos y los ejecuta de forma transaccional. Existe operación de apertura y cierre de sesión. Una sesión abierta se puede revertir. Diagrama Modelos de Contrato de Servicios open Tr A close C S /session/123 [PUT] { ... } /session/123 [PUT] { ... } /session/123 [PUT] { ... } C S/session/123 [200] - { rel: 'self' link: '/123' action: 'get' rel: 'add' link: '/123' action: 'put' rel: 'commit' link: '/123' action: 'post' rel: 'revert' link: '/123' action: 'del' } C S /session/123 [POST] { ... } C S /session/123 [201] - OK Solución Una solución de nivel #3 permite gestionar la sesión transaccional cómodamente
  • 33. Modelos de API Para El Diseño de Servicios Language Driven API Un servicio acepta una expresión sintáctica que es capaz de procesar en un contexto de ejecución y devolver un resultado. Modelos de Contrato de Servicios Diagrama Exp A Entorno de Ejecución Exp B C S /engine [POST] – { query : 'user(id: 1) { name age friends { name } }' } C S /engine [200] - Ok Una solución de nivel #2 resulta en un contrato demasiado rígido para este caso C S /users/1 [GET] /users/1/friends [GET] Una solución de nivel #1 resulta lo mejor para un servicio con modelo de lenguaje Solución
  • 34. Modelos de API Para El Diseño de Servicios Process Driven API Un servicio realiza un proceso de larga duración. La gestión de estado debe ser responsabilidad del cliente. Modelos de Contrato de Servicios Diagrama A B C C S /process [GET] C S /engine [200] – { rel: 'A' link: '/132' } C S /process/123 [GET] C S /engine [200] – { rel: 'B' link: '/234' } C S /process/234[GET] C S /engine [200] – { rel: 'C' link: '/345' } Una solución de nivel #3 permite un modo dialógico idóneo para avanzar un proceso Solución
  • 35. Modelos de API Para El Diseño de Servicios Protocol Driven API Un servicio coordina la actividad coopera- tiva que se da entre dos agentes. Deben mantenerse las propiedades de integridad y vivacidad del protocolo. Modelos de Contrato de Servicios Diagrama wait Bid Ready Price C S /auctions [GET] C S /auctions [200] – [ { rel: 'auction' link: '/123' } { rel: 'auction' link: '/456' } { rel: 'auction' link: '/789' } ] C S /auction/123 [GET] C S /auction/123 [200] – { rel : 'bid' link : '/123' action : 'post' schema : { amount: 'Integer' } } Una solución de nivel #3 permite un modo dialógico idóneo para control de protocolos Solución
  • 36. Modelos de API Para El Diseño de Servicios Protocol Driven API Un servicio coordina la actividad coopera- tiva que se da entre dos agentes. Deben mantenerse las propiedades de integridad y vivacidad del protocolo. Diagrama Modelos de Contrato de Servicios wait Bid Ready Price C S /auction/123 [POST] – { amount : 10 } Una solución de nivel #3 permite un modo dialógico idóneo para control de protocolos C S /auction/123 [200] – Ok { rel : 'bid' link : '/1231' action : 'post' schema : { amount: 'Integer' } } C S /auction/1231 [POST] – { amount : 10 } C S /engine [403] – Forbidden { rel: 'A' link: '/1321' } Solución
  • 37. Modelos de API Para El Diseño de Servicios Modelos de Contrato de Servicios Solución Una solución de nivel #2 permite un modo de asignación de buzones operativo Message Driven API Se pretende implementar un sistema de mensajería para articular comunicación entre cliente desacoplada espacial y temporalmente. Diagrama A B C Usuario A Usuario B to: B from: A C S /mailbox/A [POST] – { ... } C S /mailbox [201] – Ok C S /mailbox/B [GET] – { ... } C S /mailbox [200] – [ { id: 1, from: 'A', body: '...' } { id: 1, from: 'A', body: '...' } { id: 1, from: 'A', body: '...' } ]
  • 38. Modelos de API Para El Diseño de Servicios Stream Driven API Se pretende dar soporte a un mecanismo de comunicación asíncrono basado en eventos. La consumición de los eventos es independiente por cliente Modelos de Contrato de Servicios Solución Una solución de nivel #2 permite un modo de asignación de buzones operativo Diagrama A B C Usuario C Usuario A topic: X Usuario B X A B C C S /streams [201] – Ok C S /streams/user/B/topic/X [GET] C S /streams/user/B/topic/X [200] – { ... } /streams/topic/X [POST] – { ... } C S
  • 39. Hacia una Arquitectura Centrada en el Dominio En el diseño de arquitecturas de servicio deberíamos guiarnos por la abstracción para crear soluciones desacopladas
  • 40. Modelos de API Para El Diseño de Servicios Diseño Centrado en el Contrato Diseño Abstracto Bajo Acoplamiento Orientación a Dominio Dependencias Inversión Contrato Estructura Colaboración Implementación Tecnología Protocolo Mensaje Estado Red Patrón Modelo Lenguaje Catálogo Contexto Proceso
  • 41. Modelos de API Para El Diseño de Servicios Arquitectura de Servicios Nivel de Cliente Nivel de Servicio Modelos de Comunicación Modelos de Comunicación Modelos de Servicio Modelos de Cliente Nivel de Protocolo
  • 42. Modelos de API Para El Diseño de Servicios Arquitectura de Servicios. Nivel de Protocolo NiveldeServicio Nivel 0Nivel 1Nivel 2Nivel 3 Enpoints Fijos Acciones Fijas Estado Libre Enpoints Fijos Estado Fijo Enpoints Fijos Acciones Libres Estado Libre Enpoint Estado & Acciones Libres NiveldeCliente
  • 43. Modelos de API Para El Diseño de Servicios import Command from 'Commands' @Command class Account { constructor () {} @Process execute(command) {} } Arquitectura de Servicios. Nivel de Servicio Nivel de Servicio NiveldeProtocolo
  • 44. Modelos de API Para El Diseño de Servicios import Command from 'Commands' @Command class Account { constructor () {} @Process execute(command) {} } Arquitectura de Servicios. Nivel de Servicio Nivel de Servicio import Session from 'Transactions' @Session class Account { constructor () {} @Open create () {} @Task task (task) {} @Commit commit () {} @Revert revert () {} @Close end () {} } NiveldeProtocolo
  • 45. Modelos de API Para El Diseño de Servicios import Command from 'Commands' @Command class Account { constructor () {} @Process execute(command) {} } Arquitectura de Servicios. Nivel de Servicio Nivel de Servicio import Session from 'Transactions' @Session class Account { constructor () {} @Open create () {} @Task task (task) {} @Commit commit () {} @Revert revert () {} @Close end () {} } import Protocol from 'Protocols' @Protocol class Auction { constructor () {} @State init (ctx) { return ctx } @State ready (ctx) { return ctx } @State wait (ctx) { return ctx } @State end (ctx) { return ctx } } NiveldeProtocolo
  • 46. Modelos de API Para El Diseño de Servicios Arquitectura de Servicios. Nivel de Protocolo NiveldeServicio Nivel 0Nivel 1Nivel 2Nivel 3 Enpoints Fijos Acciones Fijas Estado Libre Enpoints Fijos Estado Fijo Enpoints Fijos Acciones Libres Estado Libre Enpoint Estado & Acciones Libres NiveldeCliente
  • 47. Modelos de API Para El Diseño de Servicios wc-view wc-command wc-context <wc-view id="A"/> <wc-view id="B"/> <wc-context id="C"> <wc-rule ref="A" on="tap"/> <wc-rule ref="B" on="tap"/> </wc-context> <wc-commands context="#C"> <wc-view ref="#A:tap"/> <wc-view ref="#B:tap"/> <wc-command key="cmd.X"/> <wc-command key="cmdY"/> </wc-commands> Arquitectura de Servicios. Nivel de Servicio NiveldeProtocolo Nivel de Cliente
  • 48. Modelos de API Para El Diseño de Servicios Arquitectura de Servicios. Nivel de Servicio wc-view wc-session wc-task-factory <wc-view id="A"/> <wc-taks ref="A"> <wc-task key="Tx" on="add"/> <wc-task key="Ty" on="drop"/> </wc-tasks> <wc-session ref="#A"> <wc-rule on="purchase" do="commit"/> <wc-rule on="discard" do="revert"/> </wc-commands> NiveldeProtocolo Nivel de Cliente
  • 49. Modelos de API Para El Diseño de Servicios NiveldeProtocolo Arquitectura de Servicios. Nivel de Servicio wc-view wc-controller <wc-view id="A"/> <wc-controller ref="#A #B"> <wc-rule when="init" disabled/> <wc-rule when="wait" disabled/> <wc-rule when="ready" enabled/> <wc-rule when="end" disabled/> </wc-controller> <wc-view id="B"/> Nivel de Cliente
  • 50. Modelos de API Para El Diseño de Servicios Modelos de Servicio Dirigir los esfuerzos de diseño de Servicios de acuerdo a modelos de dominio conduce a arquitecturas más flexibles y Adaptativas
  • 51. Javier Vélez Reyes @javiervelezreye javier.velez.reyes@gmail.com Madrid 30 Noviembre 2018 Modelos de API Para El Diseño de Servicios