Agrupación y anidamiento de API REST

8

Mi pregunta es sobre las mejores prácticas 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 sola llamada API que desencadenará muchas otras llamadas API (similares) para crear la misma entidad en otro sistema . Por ejemplo, para una entidad de ejemplo "usuario" :

  1. API REST de llamadas frontales: PUT ... / user
  2. Lo que imagino es que el código que escucha en la API anterior hará múltiples llamadas REST PUT para decir, por ejemplo, vendorA / user, vendorB / user, vendorC / user, internalSystemA / user, internalSystemB / user, 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 van a tener 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). Para simplificar, digamos que las funcionalidades de ejemplo son

  • Obtención,
  • Recursos humanos,
  • Administración,
  • Pago.

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

architecture rest api phpPhil
fuente

Respuestas:

3

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

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

sistema de diagrama

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

  • Envuelva cualquier API de terceros en uno de los servicios (siempre que cambie la API de un tercero, solo se debe cambiar el servicio contenedor), en este ejemplo, se puede usar una interfaz única para los servicios A y B.
  • Cree fachadas de servicio de nivel superior en función de 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 rastrear todo el proceso, ya que ocurre en un método de fachada única.
Pelican de bajo vuelo
fuente
Gracias por el esfuerzo que puso en esto. Veo que está diseñando un servicio real (jabón) (do XYZ) como el segundo nivel detrás de la API REST. Estoy de acuerdo con que sea un servicio de envoltura y todos los beneficios. Esperaba lograr lo mismo con REST con un enfoque tipo CRUD; SI, por supuesto, esta es la mejor práctica. Tenga en cuenta que he solucionado en mi pregunta la ambigüedad de la palabra "cliente" al utilizar "usuario" como entidad de ejemplo. También le expliqué al vendedor con más detalle, perdón por la confusión.
phpPhil
2

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 fallas de API del proveedor. Qué sucede si 1 proveedor falla y el resto tiene éxito. ¿Todavía consideramos que esto es un éxito o iniciamos una API de reversión (por ejemplo, eliminar usuario)

Basado en los supuestos, no diseñaré mi API en función de la implementación, como tener una API de proveedor, etc., sino puramente basada en la funcionalidad, es decir, quiénes son los usuarios de la nueva API y sus requisitos.

codedabbler
fuente