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

8

En una API REST de aplicaciones principales que cubre varios dominios relacionados, ¿tiene más sentido dividir los recursos en "áreas" según el dominio empresarial al que pertenecen o es mejor mantener un modelo único?

Por ejemplo, hay subdominios 'Ventas' e 'Inventario'. Los usuarios del sistema normalmente solo se preocupan por un dominio a la vez, pero las excepciones son posibles. Hay un concepto de 'Elemento' que existe en ambos dominios, por lo que podríamos implementar el recurso 'Elemento' de dos maneras diferentes.

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

    / sales / items /: id

    / inventory / items /: id

  2. tenga un solo 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.

ventajas de 'áreas'

  • es más fácil de entender la API para los usuarios que solo se preocupan por un solo dominio
  • es más fácil implementar recursos (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

  • no hay 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 API única que cubra todas sus necesidades

¿Es la partición de API como se describe anteriormente una forma válida de reducir la complejidad tanto del contrato como de la implementación de la API? No lo he visto mencionado en ninguna parte.

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

    
pregunta astreltsov 22.04.2015 - 10:47

2 respuestas

6

Creo que este es el ajuste perfecto para el patrón Contexto delimitado del diseño impulsado 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 (elemento). La interpretación del artículo en el contexto de ventas puede ser un poco diferente a la del contexto de inventario y eso es completamente correcto.

Para usar este patrón, debes:

  • identifique los límites de los diferentes contextos (lo que hizo en parte creando las subredes / ventas / y / inventario /)
  • identifique los recursos compartidos (elemento) y describa explícitamente cuál es la interpretación del recurso en diferentes contextos acotados
  • identifique las interacciones entre contextos acotados (que probablemente esté fuera del alcance de esta pregunta)

Nota en

  

pros de un solo modelo unificado:   No hay recursos duplicados para conceptos que pertenecen a más de uno.   dominio

Desde el punto de vista REST, el recurso no se duplica. Se puede identificar un recurso por múltiples URI, cada uno puede tener diferentes representaciones (ajustándose a un contexto acotado dado).

    
respondido por el qbd 26.04.2015 - 13:23
0

Creo que la regla de oro debería ser la siguiente.

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

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

    
respondido por el Vladislav Rastrusny 22.04.2015 - 17:31

Lea otras preguntas en las etiquetas