›

Limites du JSON et requêtes réseau

muqaddarmuqaddar Administrateur
février 2012 modifié dans Objective-C, Swift, C, C++ #1
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 ?

Réponses

  • AliGatorAliGator Membre, Modérateur
    #2
    Pour moi le seul problème c'est le volume de la requête. Et encore :

    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...
  • muqaddarmuqaddar Administrateur
    avril 2012 modifié #3
    Disons que le gars qui veut rappattrier tous ses vins, toutes ses bouteilles, il peut vite avoir 3000 records (vins, bouteilles) à  rappatrier d'un iPhone à  un iPad par exemple. L'idée, c'était de ne pas faire 3000 requêtes serveur PULL (bien qu'avec REST, ce soit pratique) suivies mais au moins de récupérer 2 array de JSON (1 pour les 1000 vins, 1 autre pour les 2000 bouteilles), et de les décortiquer à  l'arrivée.



    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...
  • wiskywisky Membre
    février 2012 modifié #4
    Pour activer la compression, il faut déjà  que le navigateur (le frameworks) gère cette possibilité:

    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.
  • BunoBuno Membre
    #5
    'muqaddar' a écrit:


    Oui, c'est pour Vinocela.


    Vinocella.... image/biggrin.png' class='bbc_emoticon' alt=':D' />
  • muqaddarmuqaddar Administrateur
    #6
    'Buno' a écrit:


    Vinocella.... image/biggrin.png' class='bbc_emoticon' alt=':D' />




    Tu comprendras bientôt... image/tongue.png' class='bbc_emoticon' alt=':P' />
  • muqaddarmuqaddar Administrateur
    #7
    'wisky' a écrit:


    Pour activer la compression, il faut déjà  que le navigateur (le frameworks) gère cette possibilité:

    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.




    OK, je vais regarder ça, ça n'a pas l'air très compliqué.

    Merci à  toi.
  • BunoBuno Membre
    #8
    'muqaddar' a écrit:


    Tu comprendras bientôt... image/tongue.png' class='bbc_emoticon' alt=':P' />


    Rhooo...encore des cachotteries...
Connectez-vous ou Inscrivez-vous pour répondre.