Limites du JSON et requêtes réseau
muqaddar
Administrateur
Salut,
Je me demandais si le format JSON pouvait poser problème si les fichiers JSON sont très lourds, proposant des centaines ou milliers d'enregistrements (et chaque enregistrement des dizaines de champs). Comprenez un array de 1000 hashes à 20 clés/valeurs en moyenne.
La seule limite est-elle celle du poids en téléchargement et des problèmes que cela peut poser ? (plus facile de planter le download d'un fichier unique que 10 ou 100 fichiers découpés...)
Mais d'un autre côté avoir une requête serveur au lieu de 100 ou 1000 c'est intéressant côté disponibilité serveur...
Qu'en pensez-vous ?
Y-a-t-il des bonnes pratiques ?
Je me demandais si le format JSON pouvait poser problème si les fichiers JSON sont très lourds, proposant des centaines ou milliers d'enregistrements (et chaque enregistrement des dizaines de champs). Comprenez un array de 1000 hashes à 20 clés/valeurs en moyenne.
La seule limite est-elle celle du poids en téléchargement et des problèmes que cela peut poser ? (plus facile de planter le download d'un fichier unique que 10 ou 100 fichiers découpés...)
Mais d'un autre côté avoir une requête serveur au lieu de 100 ou 1000 c'est intéressant côté disponibilité serveur...
Qu'en pensez-vous ?
Y-a-t-il des bonnes pratiques ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
1) C'est plus léger que du XML
2) Si tu as activé la compression gzip sur ton serveur (vérifie bien quitte à regarder ce qui transite sur le réseau quand tu fais la requête et reçoit la réponse) cela peut être assez efficace avec du JSON.
Dans tous les cas tu vas devoir échanger ces données par un moyen ou un autre. Tu peux voir si tu peux activer le download progressif sur ton serveur si jamais tu veux pouvoir reprendre un download ui aurait coupé, mais bon, en général c'est un peu le marteau pour tuer une mouche. Après tu peux voir à échanger ces données au format bplist (Binary Property List) ou autre au cas où ça serait plus efficace (même pas dit j'ai pas comparé le poids entre un JSON GZippé et un bplist), encore faut-il avoir la lib u'il faut côté serveur pour les générer (mais en Ruby ça existe si je dis pas de bêtises)
Après tout dépend du contexte. Si c'est pour vinocella, appli qu'on utilise en général chez soi donc avec le Wifi, le risque de coupure réseau est limité. Si c'est pour une appli qu'on utilise dans un contexte de mobilité plus intense (genre FoodReporter, dans la rue pour chercher un resto ou dans un resto pour consulter la carte visuelle des plats, etc) là on a moins de garantie de bien capter le réseau et il y a plus de chances de coupures, donc là ça peut valoir le coup de réfléchir à une alternative de requête segmentée... mais bon pour ton cas je me demande si c'est la peine de se prendre la tête pour gagner peu finalement...
Et donc, je me suis pas amusé à voir combien pesait un Array JSON de 1000 lignes * 20 clés/valeurs, mais bon, si ça reste au dessous de quelques centaines de kilo-octets, ça doit le faire.
1) Comment vérifier que le GZIP est activé en sortie ? Je suppose que c'est mon NGinx qui doit gérer ça, et pas l'appli ?
2) Comment est dégzippé le json à l'arrivée ? C'est automatique ? Parce que j'envoie du "application/json" dans le header de ma requête...
L'entête reçu par le serveur doit contenir :
Accept-Encoding: gzip
Pour compresser la réponse :
Il faut dans ton appli forcer la compression si cela est géré par le navigateur ayant fait la demande.
Le type mime ne change pas mais l'en codage devient : gzip.
Content-Encoding: gzip
Si le navigateur le gère, tu ne devrais rien avoir à faire pour décompresser. dans le cas contraire, il faut que tu modifie le "header" de la requête pour ajouter la gestion de l'encodage gzip et tu devra gérer la décompression à la main.
Vinocella.... /biggrin.png' class='bbc_emoticon' alt=':D' />
Tu comprendras bientôt... /tongue.png' class='bbc_emoticon' alt=':P' />
OK, je vais regarder ça, ça n'a pas l'air très compliqué.
Merci à toi.
Rhooo...encore des cachotteries...