Particionar los recursos de la API REST en áreas basadas en dominios comerciales

8

En una aplicación principal REST API que cubre varios dominios relacionados, ¿tiene más sentido dividir los recursos en 'áreas' en función del dominio empresarial al que pertenecen o es mejor mantener un solo modelo?

Por ejemplo, hay subdominios de 'Ventas' e 'Inventario'. Los usuarios del sistema generalmente solo se preocupan por un dominio a la vez, pero son posibles las excepciones. Existe un concepto de "elemento" en ambos dominios para que podamos implementar el recurso "elemento" de dos maneras diferentes.

  1. tener diferentes recursos para representar el concepto en cada dominio, cada recurso contiene solo los datos relevantes:

    / sales / items /: id

    / inventario / artículos /: id

  2. tener un único recurso con todos los datos que se utilizarán en todos los contextos:

    / items /: id

También hay muchos recursos que solo pertenecen a uno de los dominios.

pros de 'áreas'

  • La API es más fácil de entender para los usuarios que solo se preocupan por un solo dominio
  • Recursos más fáciles de implementar (menos cosas para leer / actualizar a la vez)
  • los recursos pueden ser más especializados / optimizados para cada dominio en particular
  • capacidad de controlar el acceso a los recursos a un nivel más granular

Ventajas de un solo modelo unificado

  • sin recursos duplicados para conceptos que pertenecen a más de un dominio
  • Si un usuario necesita trabajar con múltiples dominios, solo tendrá que usar una única API que cubra todas sus necesidades

¿Es la partición API como se describió anteriormente una forma válida de reducir la complejidad tanto del contrato API como de la implementación? No lo he visto mencionar mucho en ningún lado.

¿Hay más cosas que deben considerarse para tomar una decisión a favor de cualquiera de los enfoques?

architecture rest api-design astreltsov
fuente

Respuestas:

6

Creo que este es el ajuste perfecto para el patrón de Contexto acotado de Diseño controlado por dominio.

Los modelos grandes no se escalan bien, es mejor dividirlos en modelos más pequeños (contextos limitados) y declarar explícitamente sus relaciones (entidades comunes, interacciones entre contextos limitados, etc.)

En este caso, tendría dos contextos limitados (ventas e inventario) con un recurso compartido (artículo). La interpretación del artículo en el contexto de ventas puede ser un poco diferente que en el contexto del inventario y eso está completamente bien.

Para usar este patrón, debes:

  • Identifique los límites de diferentes contextos (lo que hizo en parte al crear subroots / sales / e / Inventory /)
  • Identificar recursos compartidos (ítem) y describir explícitamente cuál es la interpretación de los recursos en diferentes contextos delimitados.
  • Identificar interacciones entre contextos acotados (lo que probablemente esté fuera del alcance de esta pregunta)

Nota sobre

Ventajas de un único modelo unificado: no hay recursos duplicados para conceptos que pertenecen a más de un dominio

Desde el punto de vista REST, el recurso no está duplicado. Un recurso puede ser identificado por múltiples URI, cada uno puede tener diferentes representaciones (ajustadas para un contexto acotado determinado).

qbd
fuente
Este enfoque parece superior en general. Solo quiero estar seguro de que no estoy pasando por alto ningún beneficio de la alternativa.
astreltsov
0

Creo que la regla general debería ser la siguiente.

Si un artículo en sí mismo es impensable sin estar relacionado con las ventas o el inventario, debe optar por la opción 1.

Si un artículo puede existir sin ninguna relación con las ventas / inventario o si esta relación no es realmente sólida en su arquitectura, puede optar por la opción 2.

Vladislav Rastrusny
fuente
Hice el ejemplo un poco más claro. El 'elemento' existe en ambos dominios, ese es el problema. Pero también hay conceptos que solo existen en uno de los dominios.
astreltsov
@astr Bueno, en este caso voto por la separación.
Vladislav Rastrusny