Diseño de API REST: múltiples llamadas frente a una sola llamada a la API


18

Estamos desarrollando una API Rest para el sitio web de comercio electrónico que será consumida por las aplicaciones móviles.

En la página de inicio de una aplicación, debemos llamar a múltiples recursos como Sliders, Top Brands, Best Selling Products, Trending Products, etc.

Dos opciones para realizar llamadas API:

Llamada única

www.example.com/api/GetAllInHome

Múltiples llamadas:

www.example.com/api/GetSliders

www.example.com/api/GetTopBrands

www.example.com/api/GetBestSellingProducts

www.example.com/api/GetTrendingProducts

¿Cuál es el mejor enfoque para el diseño de la API de descanso: llamada única o múltiple, explica los pros y los contras?

¿Qué tomará más tiempo para responder a la solicitud?

Respuestas:


14

En teoría, las llamadas simultáneas múltiples son más flexibles e igual de rápidas.

Sin embargo, en la práctica, si carga una página, y luego carga cada parte de esa página, muestra los hilanderos de carga por todas partes hasta que obtenga los resultados, el resultado es lento y desarticulado.

Por esta razón, las solicitudes de datos de AJAX deben usarse con moderación y solo cuando tiene una sección de la página que tarda en cargarse o necesita actualizarse en un ciclo diferente al resto de la página. Diga una pantalla maestra / de detalle, donde desea seleccionar una opción del maestro y mostrar el detalle correspondiente sin volver a cargar el maestro.

Un diseño común es mantener las API separadas para la flexibilidad de codificación y las preocupaciones de microservicio, pero combina el lado del servidor de datos en el sitio web. de modo que el cliente solo necesita hacer una sola llamada a su propio sitio web. Las llamadas a la API con el almacenamiento en caché adecuado deben ser rápidas dentro del centro de datos.

Además, considere NO tener llamadas a la API del cliente. simplemente genera el lado del servidor HTML. Aunque los marcos de aplicaciones de una sola página de JavaScript lo empujan por la ruta de la API. Por lo general, no es el enfoque óptimo para sitios de comercio electrónico de gran volumen.

ingrese la descripción de la imagen aquí


Gracias, en realidad, esta API se consume en las aplicaciones de Android y del teléfono, quiero saber cuándo se carga la página de inicio de la aplicación si obtengo todos los recursos como: controles deslizantes, marcas, productos en una sola llamada de API o hacer una llamada individual a la API para obtener recursos individuales cuando los usuarios se desplaza hacia abajo?
shaijut

Se aplica la misma lógica, minimice las llamadas simultáneas donde no sea necesario. Sin embargo, una aplicación le brinda un poco más de flexibilidad para descargar información en segundo plano. Es posible que desee cambiar a un enfoque GetChangesSInce (fecha)
Ewan

Así que concluye, es mejor tener una API única para llamar a todos los recursos de la página de inicio de una vez cuando se carga la página de inicio de la aplicación y tener diferentes API para controles deslizantes, marcas, etc. ?
shaijut

no a menos que tenga una razón buena por qué esas secciones no sólo se cargan con los datos de la página / Main
Ewan

Tengo la última pregunta, ¿cómo funcionarían aplicaciones como Amazon, flipkart? ¿No cargan todos los recursos de la página de inicio en una sola llamada cuando el usuario abre la aplicación? Quiero saber cuál sería el mejor enfoque para esto.
shaijut

5

TL; DR: aparte de todas las demás consideraciones de la aplicación, realizar una sola llamada sería más rápido que realizar varias llamadas. Ejecutar las llamadas de forma asincrónica puede reducir el tiempo total necesario para completar una operación dada desde la perspectiva de su usuario (que bien podría ser todo lo que necesita), pero en conjunto, el tiempo que se necesita aún sería más largo para múltiples llamadas.

Sin embargo, en su caso, no estoy seguro de que esa sea la historia completa.

Las API REST son un término ligeramente ambiguo, debido a diversas interpretaciones del documento que hicieron popular la idea. Sin embargo, incluso con la interpretación más liberal de lo que constituye una API REST, lo que tienes realmente no encaja.

El principio central es que tiene un recurso en el que desea realizar una acción. El URI identifica el recurso que le interesa, y normalmente usaría los verbos HTTP para indicar lo que desea hacer a ese recurso.

En su caso específico, todos sus métodos tienen la palabra 'get' en su nombre. Debería cambiar el verbo utilizado en la solicitud HTTP para indicar que desea 'obtener' el recurso disponible en esa ubicación.

Su esquema de URI debe representar la jerarquía lógica de los recursos que desea poner a disposición de los usuarios de su API, por lo que en su caso consideraría usar algo como /api/products?category=slidersfiltrar su colección de productos. Esto significa que cuando los clientes desean obtener todos sus productos, simplemente pueden omitir la cadena de consulta.


Gracias, entonces, ¿quiere decir solo urlpara API pero la solicitud de diferentes recursos se debe hacer usando Query String? , también verifique esto .
shaijut

Sí, ejecutar sus llamadas de forma asincrónica reduciría el tiempo absoluto necesario para recuperar los datos, pero en conjunto, el tiempo necesario será aún mayor; Más llamadas tienen que repetir la sobrecarga de una conexión TCP y un viaje de ida y vuelta de comunicaciones. Incluso el uso de características como keep-aliveno va a eliminar esto por completo.
richzilla

La categoría sería una propiedad de un recurso de producto individual. Lógicamente, estaría buscando una colección de productos y filtrando todos aquellos con la categoría especificada
richzilla

Entonces, ¿quiere decir que cuando el usuario abre la página de inicio de la aplicación, una llamada debe ir a la API que devuelve todos los recursos mencionados anteriormente? o cuando se desplaza, se deben hacer llamadas individuales para recursos específicos, ¿cuál es la mejor práctica?
shaijut

Depende de lo que su usuario espere ver en cada punto de su aplicación. Tome este sitio web, por ejemplo, cuando haga clic en questionsverá que el URI es /questions, cuando haga clic en una de sus etiquetas favoritas, el URI es/questions/tagged/<tagname>
richzilla
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.