Cómo diseñar una API REST para un agregado con objetos anidados?

Estoy diseñando mi primer REST-API y estoy teniendo dificultades para diseñar la API de un agregado “Cart” que tiene objetos anidados:

Cart 1->n SubCart 1->n CartItem.

El agregado “Cart” se guarda como un todo. Cada vez que se coloca un artículo en el carrito, se deben calcular varios descuentos que dependen de otros “CartItem”, incluso de otros “SubCart”. Por lo tanto, la aplicación cliente necesita recibir un agregado “Cart” completo con todos los objetos anidados.

Evens menciona en su libro de DDD que “… la raíz es el único miembro del AGGREGATE al cual se le permite a objetos externos hacer referencias…”.

Entiendo la idea general, pero no está claro qué significa referencia. Algunos artículos hablan sobre referencias de objetos en memoria, otros hablan también sobre referencias de ID. Si el usuario, por ejemplo, quiere aumentar la cantidad de un “CartItem”, la interfaz de usuario debe tener una forma de identificar el artículo en el carrito. Necesita tener algún ID o referencia. De lo contrario, ¿cómo sabrá el “Cart” qué cantidad de artículo debe aumentarse? ¿Qué quiso decir Evans con referencia? La forma en que está redactado es muy confusa.

Dado que todos los comandos pasan a través del agregado “Cart” en el backend, me pregunto si esto también debería aplicarse a la API REST. Como carezco de experiencia, no sé qué problemas o efectos secundarios tendrá una u otra solución (como por ejemplo, el almacenamiento en caché, la seguridad). ¿Por qué se preferiría una u otra?

Por ejemplo, para actualizar la cantidad de un “CartItem”, veo las siguientes opciones:

PATCH carts/{id}/subcarts/{subcart_id}/cartitems/{cartitem_id}.

PATCH carts/{id}/{subcart_id}/{cartitem_id}.

PATCH /carts/{id}?subcart={subcart_id}&cartitem={cartitem_id}.

PATCH carts/{id} teniendo “subcart_id” y “cartitem_id” en el cuerpo.

Vi que la API de GIT usó la forma más corta de la opción 2 en algunos casos. ¿Cuándo se debería elegir la opción 1 en lugar de la opción 2?

Para las opciones 3 y 4, sería natural devolver el nuevo objeto “Cart” con los posibles descuentos como resultado del “PATCH”.

Con las opciones 1 y 2, no parece RESTful devolver un objeto “Cart” después de un “PATCH” de un “CartItem”. El retorno podría ser un 204 y luego el cliente deberá enviar un “GET” en el “Cart” nuevamente, lo que resulta en dos llamadas.

Gracias por cualquier ayuda y conocimientos.

davy.ai

July 12, 2023 at 9:12 pm

Diseñar una API REST para un agregado de Cart con objetos anidados puede ser desafiante, especialmente cuando se trata de actualizar los objetos anidados. Aquí hay algunas sugerencias para diseñar una API REST para un agregado de Cart con objetos anidados:

1. Diseñar la Ruta

Para diseñar la ruta para actualizar la cantidad de un CartItem, podrías usar cualquiera de las siguientes opciones:

PATCH /carts/{id}/subcarts/{subcart_id}/cartitems/{cartitem_id}
PATCH /carts/{id}/{subcart_id}/{cartitem_id}
PATCH /carts/{id}?subcart={subcart_id}&cartitem={cartitem_id}
PATCH /carts/{id} teniendo subcart_id y cartitem_id en el cuerpo.

Ten en cuenta que la ruta elegida debería ser fácil de entender para los usuarios de la API y debería seguir los principios de diseño RESTful.

2. Devolver una Respuesta

Para las opciones 3 y 4, podrías devolver el objeto Cart actualizado con posibles descuentos como resultado del PATCH. Sin embargo, para las opciones 1 y 2, no sería RESTful devolver un objeto Cart después de un PATCH de un CartItem. En su lugar, podrías devolver una respuesta 204 No Content, y el cliente tendría que enviar una solicitud GET para recuperar el objeto Cart con la cantidad de CartItem actualizada.

3. Mantener referencias sólo al agregado raíz

Recuerda que según los principios del Diseño Dirigido por el Dominio, el agregado raíz es el único miembro del AGGREGATE al cual se le permite a los objetos externos mantener referencias. Esto significa que en la API, la aplicación cliente solo debe mantener una referencia al objeto Cart y no a los objetos anidados como SubCart o CartItem.

4. Elegir el Tipo Correcto de Referencia

Cuando se trata de mantener una referencia a un objeto anidado, no está claro qué significa “referencia” en este contexto. Podría referirse a una referencia de objeto en memoria o a una referencia de ID. Sin embargo, se recomienda utilizar referencias de ID.

5. Considerar los Efectos Secundarios

Cuando se diseña una API REST para un agregado de Cart con objetos anidados, es importante considerar cualquier posible efecto secundario como el almacenamiento en caché o la seguridad. Se recomienda consultar con desarrolladores o arquitectos experimentados para asegurarse de que el diseño sea eficiente y seguro.

Answer

davy.ai

July 12, 2023 at 9:12 pm
Diseñar una API REST para un agregado de Cart con objetos anidados puede ser desafiante, especialmente cuando se trata de actualizar los objetos anidados. Aquí hay algunas sugerencias para diseñar una API REST para un agregado de Cart con objetos anidados:

1. Diseñar la Ruta

Para diseñar la ruta para actualizar la cantidad de un CartItem, podrías usar cualquiera de las siguientes opciones:
- PATCH /carts/{id}/subcarts/{subcart_id}/cartitems/{cartitem_id}
- PATCH /carts/{id}/{subcart_id}/{cartitem_id}
- PATCH /carts/{id}?subcart={subcart_id}&cartitem={cartitem_id}
- PATCH /carts/{id} teniendo subcart_id y cartitem_id en el cuerpo.
Ten en cuenta que la ruta elegida debería ser fácil de entender para los usuarios de la API y debería seguir los principios de diseño RESTful.

2. Devolver una Respuesta

Para las opciones 3 y 4, podrías devolver el objeto Cart actualizado con posibles descuentos como resultado del PATCH. Sin embargo, para las opciones 1 y 2, no sería RESTful devolver un objeto Cart después de un PATCH de un CartItem. En su lugar, podrías devolver una respuesta 204 No Content, y el cliente tendría que enviar una solicitud GET para recuperar el objeto Cart con la cantidad de CartItem actualizada.

3. Mantener referencias sólo al agregado raíz

Recuerda que según los principios del Diseño Dirigido por el Dominio, el agregado raíz es el único miembro del AGGREGATE al cual se le permite a los objetos externos mantener referencias. Esto significa que en la API, la aplicación cliente solo debe mantener una referencia al objeto Cart y no a los objetos anidados como SubCart o CartItem.

4. Elegir el Tipo Correcto de Referencia

Cuando se trata de mantener una referencia a un objeto anidado, no está claro qué significa “referencia” en este contexto. Podría referirse a una referencia de objeto en memoria o a una referencia de ID. Sin embargo, se recomienda utilizar referencias de ID.

5. Considerar los Efectos Secundarios

Cuando se diseña una API REST para un agregado de Cart con objetos anidados, es importante considerar cualquier posible efecto secundario como el almacenamiento en caché o la seguridad. Se recomienda consultar con desarrolladores o arquitectos experimentados para asegurarse de que el diseño sea eficiente y seguro.

Comments are closed.

es.davy.ai

¿Tienes una pregunta?