Agrupando y anidando APIs REST

7

Mi pregunta está relacionada con la mejor práctica de agregar o agrupar API REST. Tengo un escenario en el que hay muchos proveedores diferentes, fuentes de datos, etc. y creo que agrupar las API REST tendría mucho sentido para mantener el sistema mantenible.

Tengo muchos escenarios en los que habrá una llamada de API única que activará muchas otras llamadas de API (similares) para crear la misma entidad en otro sistema . Por ejemplo, para un ejemplo de "usuario" :

  1. API de REST de llamadas de front-end: PUT ... / user
  2. Lo que imagino es que el código que se escucha en la API anterior hará entonces varias llamadas REST PUT a digamos vendedor / usuario, proveedor / usuario, proveedor / usuario, sistema interno / usuario, sistema interno / usuario, etc.

Me gusta esto:

                                                            +-------------------+              
+--------+                   PUT     +-----------+  CALL    | Vendor A API      |              
|        |                 +-------> | user      +--------> |                   |              
|        |                 |         +-----------+          +-------------------+              
|        |                 |                                                                   
| Front  | PUT    +--------++  PUT   +-----------+  INSERT  +-------------------+              
| End    +------> | user    +------> | user      +--------> | Internal System   |              
|        |        +--------++        +-----------+          +-------------------+              
|        |                 |                                                                   
|        |                 |         +-----------+  CALL    +-------------------+              
|        |                 +-------> | user      +--------> | Vendor B API      |              
+--------+                   PUT     +-----------+          |                   |              
                                                            +-------------------+             
                 +                                 +                                           
                 +---------------------------------+                                           
                         Internal REST APIs                                                    

Tenga en cuenta que la entidad de ejemplo no tiene que ser "usuario", hay muchas entidades que tendrán una contraparte en las API del proveedor.

Los proveedores en este escenario proporcionan una funcionalidad diferente. Pero puede haber varios proveedores que brinden la misma funcionalidad (y el usuario elegirá el proveedor que desea usar). Por simplicidad, digamos que las funcionalidades de ejemplo son

  • Adquisiciones,
  • Recursos Humanos,
  • Gestión,
  • Pago.

¿Cuál es la mejor práctica para agrupar y anidar las API REST en este escenario? ¿Es una buena idea agruparlos por proveedor o deberían estar agrupados funcionalmente o por entidad comercial? ¿Cómo se vería la URL?

    
pregunta phpPhil 02.03.2015 - 01:55

2 respuestas

1

Iría a una agrupación más lógica,

Imagine un sistema en el que se realizan las reservas de hotel, donde hay 2 API de reserva de hotel diferentes (A y B) y una pasarela de pago.

En este tipo de situación, serían algunas de las mejores prácticas a seguir,

  • Envuelva cualquier API de terceros en uno de los servicios (siempre que los cambios de API de terceros solo se deba cambiar el servicio de envoltura), en este ejemplo se puede usar una interfaz única para los servicios A y B.
  • Cree fachadas de servicio de nivel superior basadas en la funcionalidad (en este caso, una fachada para buscar y otra para reservar)
  • Esto también ayudará a solucionar problemas, porque si hay un error, sería fácil realizar un seguimiento del proceso completo, ya que ocurre en un solo método de fachada.
respondido por el Low Flying Pelican 05.03.2015 - 04:59
1

La respuesta depende de algunas suposiciones no descritas en la pregunta: 1. No tiene la libertad de cambiar el proveedor o la API interna 2. La agrupación debe realizarse en una sola transacción. es decir, qué tan estricta debería ser la API contra las fallas de la API del proveedor. ¿Qué pasa si 1 proveedor falla y el resto tiene éxito? ¿Seguimos considerando esto como un éxito o iniciamos una API de reversión (por ejemplo, eliminar usuario)

Sobre la base de las suposiciones, no diseñaré mi API según la implementación, como tener una API de proveedor, etc., sino únicamente por la funcionalidad, es decir, quiénes son los usuarios de la nueva API y sus requisitos.

    
respondido por el codedabbler 30.04.2015 - 23:03

Lea otras preguntas en las etiquetas