Réponse JSON du service Web - Question sur les meilleures pratiques

Question

J'écris un service Web simple qui renvoie une réponse JSON. Il sera très utilisé, donc je veux essayer de rendre la réponse JSON aussi petite que possible pour des raisons de performances. Je suis sur la clôture sur une décision de conception; Penny pour vos pensées!

Ma réponse JSON du serveur ressemble à ceci:

{ 
    "customers": 
    [ 
    { 
     "id": "337", 
     "key": "APIfe45904c" 
    }, 
    { 
     "id": "338", 
     "key": "somethingDifferent" 
    }, 
    { 
     "id": "339", 
     "key": "APIfe45904c" 
    }, 
    { 
     "id": "340", 
     "key": "APIfe45904c" 
    } 
    ] 
} 

Le APIfe45904c ici est utilisé dans environ 60 à 70% des dossiers, pour que je puisse modifier aussi la réponse JSON pour supprimer les informations répétées et ajouter un default_key à savoir s'il n'y a pas key spécifié, le client doit assumer le default_key comme ceci:

{ 
    "default_key": "APIfe45904c", 
    "customers": 
    [ 
    { 
     "id": "337" 
    }, 
    { 
     "id": "338", 
     "key": "somethingDifferent" 
    }, 
    { 
     "id": "339" 
    }, 
    { 
     "id": "340" 
    } 
    ] 
} 

aucun client utilise le service Web encore, donc ce ne serait pas casser quoi que ce soit. Est-ce une bonne pratique? Cela fonctionne et donne une petite réponse JSON, mais je suis en conflit. J'aime le principe KISS pour les développeurs utilisant le service, mais je veux aussi une réponse JSON aussi petite que possible.

je tenté de remplacer customers avec c, id avec i et key avec k pour aider à réduire la taille du fichier, mais je me suis dit que ce sera un problème si je veux obtenir d'autres clients de commencer à l'utiliser. Devrais-je abandonner l'idée de default_key pour la même raison?

Chaque réponse JSON sera probablement pas plus de 200 lignes de id/paires de clés, donc je ne pas besoin d'intégrer la pagination, etc.

Answer 1

je garderais simple comme vous le dites, puis utilisez gzip pour comprimez-le. Il devrait très bien se comprimer car il est répétitif, et reste pratique pour les programmeurs.

Voir ici pour des pointeurs en sortie têtes gzip pour AJAX: Is gzip encoding compatible with JSON?

Answer 2

Sauf si vous avez des besoins très particuliers de performance, je toujours choisir la clarté sur la concision. Surtout pour une API qui va être utilisée par de nombreux développeurs.

Answer 3

Vous devez utiliser le format cohérent dans lequel chaque enregistrement a un champ id et un champ key. Ce que vous perdez en bande passante, vous gagnez à ne pas avoir à pré-traiter le JSON sur le côté client.

J'ai tendance à analyser ma structure de données JSON comme vous, mais à la fin cela ne vaut pas le petit espace que vous économisez. Votre structure de données JSON semble bonne ... avez-vous vu la structure de données JSON de Twitter? Maintenant c'est moche.

Answer 4

Je voudrais aller avec l'idée clé par défaut, mais je n'irais pas jusqu'à raccourcir les noms d'attributs, car cela peut être source de confusion. Vous pouvez peut-être prendre un argument de l'appel de service Web (à partir de la chaîne de requête) qui spécifie si le client souhaite ou non avoir des noms d'attribut raccourcis.