restful nodejs microservicios infraestructura estrategia entre ejemplo diferencia desarrollo desarrollador basado arq rest soa microservices

rest - nodejs - microservicios ejemplo



¿Qué son REST, RESTFul, SOA y microservicios en términos simples? (2)

Permítanme presentarles una visión taxonómica de esos términos:

Microservicios

Son un subtipo de servicios especializados por mínima responsabilidad.

Servicios web

también son un subtipo de servicios, especializados por el tipo de servicio que brindan y que se ajustan a los requisitos y necesidades de la web.

SOA

es un subtipo de arquitecturas y, por lo tanto, una vista estructural de algunos componentes y sus relaciones, donde pasa a ser servicios y comunicaciones entre esos servicios, respectivamente.

descanso

Es un subtipo de comunicación, protocolo http subyacente.

sosegado

es un subtipo de arquitecturas (una vista estructural de algunos componentes y sus relaciones) donde se especializa por relaciones entre componentes restringidos para ser comunicaciones de descanso.

Pensé que sabía lo que eran REST / "RESTFul", restfulservices, webservices, SOA y microservices, pero encontré tantas definiciones diferentes que llegué a la conclusión de que esos términos están sobreutilizados, mal utilizados o simplemente mal definidos.

Espero tener una comprensión clara de lo que representan los términos antes mencionados, su definición concreta, sus puntos en común y sus diferencias, las ventajas frente a las desventajas y, lo que es más importante, la conclusión: las cosas más importantes que se deben recordar para utilizar esos términos de manera adecuada.


Descargo de responsabilidad: la mayoría de esta publicación es subjetiva. Aquí no se ha intentado definir estrictamente nada, solo se trata de contextualizar y ofrecer una visión global de los conceptos y cómo se relacionan entre sí.

Pensé que sabía qué REST / "RESTFul", restfulservices, webservices, SOA y microservices

Yo diría que todos estos términos caen en el paraguas de Service Oriented Architectures (SOA). Servicios web es una SOA que utiliza tecnologías relacionadas con la web. REST y su subconjunto REST son un conjunto de prácticas para implementar servicios web. Finalmente, los microservicios son un nuevo conjunto de prácticas SOA.

Espero tener un claro entendimiento de lo que representan los términos antes mencionados.

Trataré de abordar este punto, pero utilizando definiciones informales y sin entrar en ventajas y desventajas. Eso sería demasiado largo y creo que los puntos más importantes deberían ser obvios a partir de las explicaciones.

SOA

Creo que el nombre se explica por sí mismo en este caso: SOA, que significa Arquitectura Orientada a Servicios , se refiere a arquitecturas diseñadas con un enfoque en servicios. Ahora, la parte difícil aquí es lo que puede o no considerar un servicio y ese es un tema completamente diferente.

servicios web

Esto explica el subconjunto de SOA que utiliza tecnologías relacionadas con la web. Esto normalmente implica HTTP y XML, pero también podría usar FTP. Creo que el término web aquí es bastante vago, ya que generalmente se refiere a tecnologías estándar de Internet.

Sosegado)

REST es un subconjunto de servicios web, y por lo tanto una SOA, que gira en torno al uso de HTTP para la comunicación. Existe un cierto conjunto de prácticas comunes, como una cierta relevancia dada a las URL.

Hace unos 10 años, cuando me presentaron a REST, se me presentó a REST como una implementación de REST más estricta en la que un recurso tendría un URI único y se manejaría mediante operaciones CRUD asignadas a verbos HTTP - Crear = POST, Leer = GET, Update = PUT, Delete = Delete .

La actualización de la información del usuario a través de una solicitud HTTP GET o POST oa /users/1/update sería perfectamente válida en REST, pero no sería REST. Para este último, el enfoque sería utilizar un PUT o PATCH HTTP sobre /users/1 (que también sería la URL para el resto de las operaciones, simplemente variando el verbo HTTP).

Encuentro que estas distinciones se han desdibujado con los años. Sin embargo, aún se mantiene que RESTful es un subconjunto más estricto de REST. (Los requisitos exactos pueden ser discutibles.)

EDITAR - Una definición más formal:

REST significa Representational State Transfer y fue presentado por Roy Fielding en su Ph.D. Tesis como estilo arquitectónico para sistemas hipermedia distribuidos. El énfasis está en la hipermedia y la autocontención, que disocian al cliente de la mayoría de los conocimientos previos, entre otros. Un sitio web es un ejemplo: consiste en un solo URI (la raíz del sitio web) y un tipo de medio (HTML) a través del cual el servidor ofrece toda la información que un cliente necesita con respecto a los recursos y todas las posibles interacciones.

Yo diría que el 99% de las personas que hablan de REST realmente se refieren a interfaces basadas en RPC o HTTP : el uso de puntos finales HTTP para invocar ciertas acciones o datos de consulta. Fielding mismo ha tratado de aclarar esto . Cualquier API formada por un conjunto de URL predefinidas que esperan ciertos verbos HTTP y algunos parámetros cae en ese 99%. Lo mismo ocurre con mi descripción anterior. Sin embargo, dudo que el término en sí pueda sobrevivir a su mal uso y creo que debemos aceptar su nuevo significado.

Microservicios

Este es el término más reciente; promueve la implementación de aplicaciones como un conjunto de servicios sencillos de implementación independiente. Esto contrasta con el enfoque clásico de las arquitecturas SOA como un conjunto de servicios bastante complejos utilizados para construir sistemas complejos, que típicamente involucran un bus de servicio empresarial. Sin embargo, es importante tener en cuenta que, aunque típicamente SOA se asocia con dichos sistemas, es un término más amplio y, de hecho, los microservicios también son un subconjunto de SOA.

Los microservicios suelen aparecer mano a mano con las pilas completas de JavaScript modernas, es decir, utilizando JavaScript para todos los componentes verticales, desde el servidor hasta la interfaz de usuario. Podría decirse que esto es así porque el uso de estas pilas completas de JavaScripts puede acelerar el desarrollo gracias a la integración simplificada. Estas pilas, y por lo tanto los microservicios implementados usándolas, generalmente se diseñan a través de REST, pero desde un punto de vista teórico, no hay nada que le impida utilizar un enfoque diferente de la misma filosofía.