Estoy intentando construir un servicio web RESTful que se supone que alimentará mi UI. Si sigo los principios HATEOAS puros, solo debería exponer los URI de los recursos individuales en colecciones. Ahora, supongamos que tengo una relación padre-hijo, y cada padre puede tener como 50 hijos, y la IU requiere datos parciales para que todos los hijos también se muestren cuando se hace clic en el padre.Pure HATEOAS vs hacer demasiadas llamadas de servicio
Si solo expongo los URI secundarios con el padre, entonces la IU tendrá que realizar 50 llamadas al servicio web para hacer esto. El otro enfoque es tener una API separada que proporcione la información principal y parcial sobre los niños en lugar de solo los URI. Estoy seguro de que este es un problema bastante común. ¿Cuál es el equilibrio correcto aquí? ¿Cuáles son algunos de los problemas? El enfoque de "solo URI" es más limpio desde el punto de vista del diseño, pero podría hacer que la IU realmente fuera más lenta y generara mucha carga en el servidor debido a todas estas llamadas de servicio. Entonces, el otro enfoque podría ser más práctico. En tu experiencia, ¿qué es mejor?
k .. gracias! Pero en la práctica, ¿realmente es un dolor si tienes que hacer demasiadas llamadas? –
@ Raze2dust Encontrará que la mayoría de los enlaces que debe seguir de forma redundante se pueden guardar en caché de forma segura. Entonces, aunque se siente como muchas llamadas HTTP, la mayoría de los viajes redondos de la red pueden optimizarse. Además de incorporar partes de los recursos secundarios en la representación de los padres, puede crear una API muy eficiente en cuanto a la red. –
Aunque hay un impacto en la capacidad de caché de usted, utilice la inserción de HAL como si no pudiera usar una memoria caché http vana. O si puede (ignore la inserción), entonces no está utilizando la memoria caché de manera eficaz. – dietbuddha