Conception de l'API REST: plusieurs appels contre un seul appel à l'API


19

Nous développons une API Rest pour le site Web de commerce électronique qui sera utilisée par les applications mobiles.

Dans la page d'accueil d'une application, nous devons appeler plusieurs ressources telles que Sliders, Top Brands, Best Selling Products, Trending Products etc.

Deux options pour effectuer des appels API:

Appel unique:

www.example.com/api/GetAllInHome

Appels multiples:

www.example.com/api/GetSliders

www.example.com/api/GetTopBrands

www.example.com/api/GetBestSellingProducts

www.example.com/api/GetTrendingProducts

Quelle est la meilleure approche pour la conception d'une API de repos - appel simple ou multiple, expliquez les avantages et les inconvénients?

Laquelle prendra plus de temps pour répondre à la demande?

Réponses:


14

En théorie, les multiples appels simultanés sont plus flexibles et tout aussi rapides.

Cependant, dans la pratique, si vous chargez une page, puis chargez chaque partie de cette page, en affichant des filateurs de chargement partout jusqu'à ce que vous obteniez les résultats, le résultat est lent et décousu.

Pour cette raison, les demandes de données AJAX doivent être utilisées avec parcimonie et uniquement lorsque vous avez une section de la page qui est lente à charger ou doit être actualisée sur un cycle différent du reste de la page. Dites un affichage maître / détail, où vous souhaitez sélectionner une option du maître et afficher le détail correspondant sans recharger le maître.

Une conception courante consiste à conserver les API distinctes pour la flexibilité de codage et les problèmes de micro-service, mais à combiner le côté serveur de données dans le site Web. afin que le client ne doive effectuer qu'un seul appel vers son propre site Web. Les appels d'API avec une mise en cache appropriée doivent être rapides dans le centre de données.

En outre, envisagez de n'avoir AUCUN appel d'API client. générer simplement le côté serveur HTML. Bien que les frameworks d'application à page unique javascript vous poussent sur la route de l'API. Ce n'est généralement pas l'approche optimale pour les sites de commerce électronique à volume élevé.

entrez la description de l'image ici


Merci, en fait, cette API est consommée dans les applications Android et i Phone, je veux savoir quand la page d'accueil de l'application est chargée si j'obtiens toutes les ressources comme: les curseurs, les marques, les produits en un seul appel API ou faire un appel individuel à l'API pour une ressource individuelle lorsque les utilisateurs défilent vers le bas?
shaijut

La même logique s'applique, minimisez les appels simultanés lorsque cela n'est pas nécessaire. Une application vous donne cependant un peu plus de flexibilité pour télécharger des informations en arrière-plan. Vous voudrez peut-être passer à une approche GetChangesSInce (date)
Ewan

Donc, vous concluez, il est préférable d'avoir une API unique pour appeler la réponse de toutes les ressources de la page d'accueil à la fois lorsque la page d'accueil de l'application se charge et avoir des API différentes pour les curseurs, les marques, etc. séparément pour le micro-service lorsque vous avez une section de la page à mettre à jour ?
shaijut

sauf si vous avez une bonne raison pour laquelle ces sections ne sont pas simplement chargées avec la page / les données principales
Ewan

J'ai une dernière question: comment fonctionneraient des applications comme amazon, flipkart? Ne charge-t-il pas toutes les ressources de la page d'accueil lors d'un seul appel lorsque l'utilisateur ouvre l'application? Je veux savoir quelle serait la meilleure approche à ce sujet.
shaijut

5

TL; DR: Toutes les autres considérations d'application mises à part, effectuer un seul appel serait plus rapide que d'effectuer plusieurs appels. L'exécution des appels de manière asynchrone peut réduire le temps global nécessaire pour terminer une opération donnée du point de vue de votre utilisateur (ce qui pourrait bien être tout ce dont vous avez besoin), mais dans l'ensemble, le temps nécessaire serait encore plus long pour plusieurs appels.

Dans votre cas cependant, je ne suis pas sûr que ce soit l'histoire complète.

Les API REST sont un terme légèrement ambigu, en raison de diverses interprétations du document qui ont rendu l'idée populaire. Cependant, même par l'interprétation la plus libérale de ce qui constitue une API REST, ce que vous avez ne correspond pas vraiment.

Le principe de base est que vous disposez d'une ressource sur laquelle vous souhaitez effectuer une action. L'URI identifie la ressource qui vous intéresse et vous utiliseriez normalement les verbes HTTP pour indiquer ce que vous voulez faire pour cette ressource.

Dans votre cas spécifique, toutes vos méthodes ont le mot «get» dans leur nom. Vous devez modifier le verbe utilisé dans la demande HTTP pour indiquer que vous souhaitez «obtenir» la ressource disponible à cet emplacement.

Votre schéma d'URI doit représenter la hiérarchie logique des ressources que vous souhaitez mettre à la disposition des utilisateurs de votre API, donc dans votre cas, j'envisagerais d'utiliser quelque chose comme /api/products?category=sliderspour filtrer votre collection de produits. Cela signifie que lorsque les clients souhaitent obtenir tous vos produits, ils peuvent simplement omettre la chaîne de requête.


Merci, donc vous voulez dire unique urlpour l'API, mais la demande de ressources différentes doit être effectuée à l'aide de la chaîne de requête? , vérifiez également cela .
shaijut

Oui, l'exécution de vos appels de manière asynchrone réduirait le temps absolu nécessaire pour récupérer les données, mais dans l'ensemble, le temps nécessaire sera encore plus long; Plus d'appels doivent répéter la surcharge d'une connexion TCP et un aller-retour de communications. Même en utilisant des fonctionnalités comme celles-ci, cela keep-alivene supprimera pas complètement cela.
richzilla

La catégorie serait la propriété d'une ressource de produit individuelle. Logiquement, vous
iriez

vous voulez dire, lorsque l'utilisateur ouvre la page d'accueil de l'application, un appel doit aller à l'API qui renvoie toutes les ressources mentionnées ci-dessus? ou quand il fait défiler, des appels individuels doivent être faits pour des ressources spécifiques, quelle est la meilleure pratique?
shaijut

Cela dépend de ce que votre utilisateur attend de voir à chaque point de votre application. Prenez ce site Web par exemple, lorsque vous cliquez sur questionsvous voyez que l'URI est /questions, lorsque vous cliquez sur l'un de vos tags préférés, l'URI est/questions/tagged/<tagname>
richzilla
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.