Quelle est la taille de réponse idéale à considérer lors de la conception d'objets et de sous-objets API
Nous travaillons avec une métrique de performance à laquelle toutes les demandes d'API devraient répondre dans les 50 ms lors de l'exécution locale. Je prends cela à partir du temps de réponse moyen de Githubs API .
J'ai un objet appelé Foo. Un seul Foo peut contenir 6 Ko de texte lorsqu'il est sérialisé en json.
Foo a un sous-objet qui représente environ 3 Ko appelé Bar.
Il y a un point final dans mon API qui renvoie une page de Foos à la fois, par exemple:
https: // apidomain/v1/foos? pageSize = 25
La réponse pour une seule page de 25 Foos est alors d'environ 150 Ko. Cela prend 75 ms pour répondre lors de l'exécution locale.
Il existe une option de conception pour retirer les barres de l'objet Foos et les rendre disponibles en tant que sous-objet comme ceci:
https: // apidomain/v1/foos/fooId123/bar
Cela porterait la réponse pour une seule page de 25 foos à 75 Ko. Avec une demande supplémentaire nécessaire pour obtenir la barre pour ce foo. Cela rapproche le temps de réponse moyen de l'objectif de 50 ms.
Lors de la conception d'une API RESTful et de ses définitions d'objet, quelle est la taille de réponse idéale si 50 ms est un temps de réponse idéal ?
Quelles autres considérations dois-je avoir lors de la conception d'objets et de sous-objets API?
Je pense qu'il est important de faire la distinction entre signifie temps de réponse et absolu temps de réponse. Selon la page de métriques à laquelle vous avez lié, c'est exactement ce que fait le GitHub. Ils suivent 2 métriques concernant les temps de réponse:
- moyenne (moyenne)
- 98e centile
Cela donne 2 images: le temps de réponse auquel la plupart des gens vont faire face et le pire temps de réponse que les gens doivent gérer.
La question suivante est de savoir où vous mesurez le temps de réponse. Si vous mesurez le temps de réponse à partir des journaux d'accès au serveur Web (comme le font la plupart des gens), vous mesurez le delta entre la réception de la demande et l'heure à laquelle le serveur envoie la réponse - sans compter le temps de transfert. Si vous mesurez le temps de réponse à partir de l'onglet développeur d'un navigateur, vous mesurez le temps entre l'envoi de la demande et le moment où la réponse est entièrement reçue, ce qui inclut 2 trajets réseau dans le calendrier.
Réduction du temps réseau
Vous ne pouvez pas faire grand-chose pour améliorer le temps de transfert des données. Les vitesses du réseau sont généralement limitées dans les endroits que vous ne contrôlez pas. Cependant, vous pouvez effectuer les opérations suivantes:
- Activez compression HTTP . JSon et XML sont très compressibles, vous pourriez donc également économiser de l'argent.
Mesures cohérentes
Assurez-vous de savoir ce que vous mesurez et pourquoi ces mesures existent. Gardez à l'esprit que nous, les humains, avons du mal à percevoir les différences de temps inférieures à 100 ms (1/10e de seconde).
Concevez selon vos besoins
Concevez vos API autour de ce dont vous avez besoin. Si quelque chose devient un véritable goulot d'étranglement, vous pouvez voir comment vous pouvez vous améliorer ou vous optimiser à ce moment-là.
- Si vous avez des clients qui ont besoin de la charge utile complète, disposez d'un point de terminaison API pour cette charge utile complète.
- Si vous avez des clients qui ont besoin d'une charge utile abrégée, disposez d'un point de terminaison API pour cette charge utile abrégée
- Ne pensez pas aux tailles de données absolues. Pensez au besoin réel. Le renvoi des ensembles de données appropriés minimise les appels d'API.
Il est courant d'avoir besoin d'une liste de données récapitulatives, puis de demander une charge utile complète lorsque l'utilisateur est prêt à explorer les informations.
La taille de réponse idéale pour toute demande est la plus petite taille possible qui contient toutes les informations dont le client a besoin. Demander aux clients de faire plusieurs demandes est inefficace et doit être évité.
Il semble que vous ayez plusieurs clients qui ont besoin de différents sous-ensembles d'informations, qui envoient comme cela met ces deux exigences en contradiction. Afin d'empêcher le client A de faire plusieurs demandes, il semble que vous deviez envoyer des données dont le client B n'a pas besoin. Mais ce que vous pouvez faire est inclure une option dans la demande qui spécifie quel sous-ensemble d'informations est nécessaire. Ensuite, lorsque le client A se connecte, il peut demander des foos avec des barres incluses, tandis que le client B peut les avoir sans.
Jetez un œil à certaines des API de Google pour obtenir des exemples - elles le font souvent.