Terminología ROA

Términos y definiciones usados en ROA comparados contra un MVC clásico

Transcript

1. Terminología ROA Términos y definiciones usados en ROA comparados contra un MVC clásico
2. Objetivos Conocer los requerimientos y políticas que componen las arquitecturas SOA y ROA. Conocer en qué se diferencian de un MVC clásico.
3. SOA
4. Definición SOA Es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Se basa en definir SERVICIOS que encapsulan la lógica de negocio para que un CONSUMIDOR externo pueda presentar la información al CIUDADANO.
5. Beneficios Facilidad y flexibilidad de CONSUMO para su integración en flujos de negocio. Segmentación de funcionalidad en SERVICIOS independientes. Respuesta ágil a cambios y solución de errores. El CIUDADANO puede decidir entre distintas presentaciones de información de forma transparente.
6. Servicio Función sin estado, auto-contenida, que acepta llamadas y devuelve respuestas mediante una interfaz y estructura de información bien definida conocida como CONTRATO. No dependen del estado de otras funciones o procesos.
7. Consumidor/Cliente Aplicación que consume uno o varios servicios de forma automatizada o a petición de un CIUDADANO. El SERVICIO y el ciudadano son independientes y pueden estar escritos en distintos lenguajes de programación por lo que el CONTRATO define cómo pueden interactuar.
8. Contrato Estructura de la información que espera recibir un servicio así como las estructuras de información de los distintos tipos de respuesta que puede devolver.
9. Ciudadano/Cliente Humano Persona que interactúa con el consumidor de un servicio para la toma de decisiones de un flujo de negocio. Esta persona puede ser un socio comercial o un consumidor final.
10. Versión Agrupación de servicios que cubren todas las lógicas de negocio para una aplicación. Crear nuevas versiones es la única forma permitida de alterar o mejor dicho crear nuevos contratos para un servicio publicado.
11. Estabilidad Una versión SOA puede entrar en distintas estabilidades dependiendo de la etapa de desarrollo y mantenimiento . Se divide en: ➔ Desarrollo ➔ Estable ➔ Deprecado ➔ Obsoleto
12. ROA
13. Definición de ROA Arquitectura representacional orientada a RECURSOS que implementan SERVICIOS REST. Toda implementación de ROA es a su vez una implementación de SOA pero lo opuesto no es cierto.
14. Recurso Representación de un componente de negocio que contiene varios servicios diferenciados por los VERBOS HTTP. Cada recurso se encarga de un único componente y en la mayoría de los casos son implementaciones CRUD mediante REST de componentes de negocio.
15. Servicios REST Servicios representacionales en base a la ruta de consumo y un verbo http. La petición debe contener toda la información necesaria para realizar el servicio y la respuesta debe contener toda la información necesaria para su uso, reutilización y acceso. Incluyendo información de cabecera como CORS.
16. Ruta La ruta es la estructura de la URI que representa un recurso rest. La ruta y el recurso se relacionan de forma biunívoca de forma que distintas rutas corresponden a distintos recursos y viceversa. e.g. api/v1/tiendas/<tienda_id>/empleados/<empledo_id>/ausencias
17. Verbo HTTP Indican la acción que se desea de un recurso definido en la especificación HTTP/1.1 GET, POST, HEAD, OPTIONS, PUT, DELETE, PATCH.
18. Código de Estado HTTP Las respuestas de un servicio REST empiezan devolviendo el código de estado de HTTP con lo que se determina el éxito de una petición. Respuestas con el mismo código de estado deben seguir la misma estructura aunque distintos códigos pueden devolver distintas estructuras
19. Cuerpo de la Respuesta El cuerpo de la respuesta es un documento XML JSON que sigue los estándares HATEOAS y JSON Hypermedia (que también soporta formato XML)
20. SOA vs ROA
21. Similitudes ROA puede verse como una implementacioń simplificada de SOA al limitar su enfoque a servicios web HTTP, optando siempre por las tecnologías soportadas por defecto y las soluciones más simples. Los servicios ROA son comúnmente más fáciles de consumir y desarrollar debido a estos motivos.
22. Enfoque de Consumo SOA Pensado para que se pueda consumir desde distintos protocolos a veces en el mismo servicio. e.g. un servicio que soporta RSS y que también soporta HTTP. ROA Enfocado a la web y al protocolo HTTP/1.1 Cada servicio es accesible sólo por este medio.
23. Requerimientos de Consumo SOA Puede requerir diversas tecnologías y protocolos para ser consumidos. e.g. instalar un cliente SOAP o WSDL y por lo tanto sólo poder utilizar lenguajes que los soportan. ROA Debe bastar con soportar HTTP/1.1
24. Cifrado SOA Ofrece varios protocolos de cifrado point-to-point y end-to-end. ROA Se usa HTTPS que es un end-to-end.
25. Ruta de Servicio SOA La nomenclatura del servicio debe ser autodescriptiva y contener la acción a realizar. users/getList ROA La ruta representa un recurso y la acción se representa mediante el verbo de HTTP. users [GET]
26. Resultado de la Respuesta SOA Los resultados pueden expresarse con distintas formas en distintos protocolos y servicios por lo que es necesario tener un control de mensajes de las respuestas de cada servicio. e.g. recibir “usuario creado con éxito” o “sucess:true” ROA Los códigos de HTTP determinan la respuesta para todos los servicios. e.g. 201 significa CREATED en cualquier servicio.
27. Interfaz de Respuesta SOA Cada protocolo y servicio puede tener distinta interfaz de respuesta por lo que la interfaz forma parte del contrato. Algunos protocolos son muy rígidos y sólo soportan un formato de respuesta, por lo general XML. ROA Se usa HATEOAS y JSON Hypermedia como interfaz de forma unificada por lo que la estructura puede ser más flexible y reducida, además de soportar formatos JSON y XML según lo solicite el consumidor
28. Resumen ROA reduce la planeación y toma de decisiones al reducir el enfoque de los servicios. Esto ofrece menos libertad al escoger tecnologías pero más agilidad y menor tiempo de respuesta para el desarrollo y una menor curva de aprendizaje.
29. MVC vs ROA
30. Rutas MVC La ruta incluye el controlador y la acción. Puede recibir los identificadores mediante parámetros GET. La misma acción puede soportar varios verbos http. ROA La ruta representa de forma única a un recurso, distintas rutas apuntan a distintos recursos. Los identificadores son parte de la ruta. Información que no pertenece a un identificador se envía por parámetros GET Cada acción soporta exactamente un verbo.
31. e.g. perfil/avatar [POST] PerfilController::actionAvatar() tienda-producto/update?tienda_id=1& producto_id=1 [POST] TiendaProductoController ::actionUpdate() banco/creditos?banco_id=1&monto=100 0 [GET] BancoController::actionCreditos() perfil/avatar [POST] PerfilAvatarController ::actionCreate() tienda/1/producto/1 [PATCH] TiendaProductoController ::actionUpdate() banco/1/credito?monto=1000 [GET] BancoCreditoController::actonIndex()
32. Trazabilidad En ROA la ruta representa un recurso y por lo tanto también representa los descendientes del recurso de forma que las subrutas también deben ser recursos accesibles. Es decir si puedo acceder a: tienda/1/producto/1 también puedo acceder a: tienda/1/producto [GET] tienda/1 [GET] tienda [GET]
33. Autentificación MVC La autentificación se realiza mediante sesiones y cookies. Los límites de consumo se determinan mediante métodos como CSRF La sesión depende del navegador. ROA No existen cookies ni sesiones. La autentificación se realiza mediante tokens enviados por un parámetro GET o cabecera Authentication. Los límites de consumo se definen mediante métodos como CORS y RateLimiter. Independiente del navegador.
34. Navegación MVC Comúnmente las rutas relacionadas se representan con enlaces HTML en una vista <a href=item/index?page=2>Next Page</a> ROA La navegación se realiza mediante cabeceras links o la propiedad: _link de json.
35. Código HTTP MVC Distintos resultados de una petición pueden ser representados en la misma vista con el mismo código HTTP ya que así lo espera un navegador. e.g. Devolver 200 cuando hay un error de validación al crear un elemento y mostrar los errores en la vista. ROA Al no depender de un navegador ni soportar vistas las respuestas REST declaran el resultado de una petición mediante el código HTTP de modo que distintos resultados devuelven distintos códigos y viceversa. e.g Devolver 422 cuando hay un error de validación al crear un elemento
36. Resumen Recursos reemplazan a controladores. Verbos reemplazan acciones. Tokens reemplazan sesiones y cookies. Las rutas pertenecen a exactamente un recurso. El resultado de una petición se interpreta mediante el código de estado HTTP de la respuesta.
37. Referencias
38. Metodos HTTP https://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol#M.C3.A9todos_de_petici.C3.B3n Códigos de Estado HTTP https://es.wikipedia.org/wiki/Anexo:C%C3%B3digos_de_estado_HTTP Control de acceso HTTP (CORS) https://developer.mozilla.org/es/docs/Web/HTTP/Access_control_CORS HATEOAS https://en.wikipedia.org/wiki/HATEOAS