Tutoriel JSON

PierrePierre Membre
juin 2010 modifié dans Actualités #1
Bonjour à  tous, j'ai trouvé un tutoriel qui expliqué bien comment appelé une API et parser le JSON renvoyé.

Le voici :



J'espère que ça va aider ceux qui cherchent à  mettre en oeuvre une application client serveur qui dialogue en JSON.
Pour infos : je suis passé d'une parser XML à  cette solution. Je suis passé de plusieurs dizaine de lignes de code difficile à  maintenir à  un code pratiquement standard. Aujourd'hui en moins de trois minutes je suis capable d'ajouter une nouvelles vue pour lire un de mes flux d'API.

Bonne lecture,
Pierre

Réponses

  • zoczoc Membre
    11:22 modifié #2
    Déjà  un reproche à  faire à  la partie 1  :D


    L'auteur suppose que la callback "didReceiveData" ne sera appelée qu'une fois et que l'objet NSData reçu contiendra l'ensemble du dictionnaire JSON, ce qui n'est pas toujours le cas.


    Il est en effet possible que cette méthode soit appelée plusieurs fois, et dans ce cas il faut concaténer l'ensemble des NSData reçus. C'est dans la méthode "connectionDidFinishLoading" qu'on est certain d'avoir reçu l'ensemble des données, pas avant.
  • AliGatorAliGator Membre, Modérateur
    juin 2010 modifié #3
    [Mode Pub]
    Quel est l'intérêt de ce tutoriel maintenant qu'on a le magnifique Ali's JSON-RPC Framework qui fait tout tout seul ? :D :)
    [/Mode Pub]

    (Bon je dis ça je sais pas si l'API Flickr est en JSON-RPC ou en JSON-REST ou même en GET pur... mais bon un coup de pub ça fait du bien ^^lol)
  • zoczoc Membre
    11:22 modifié #4
    Ouais, en fait j'ai aussi voulu parler de ton framework, mais l'API FlickR c'est du GET basique, donc pas pour ton framework  :D
  • AliGatorAliGator Membre, Modérateur
    11:22 modifié #5
    Bah je maà®trise pas le JSON-RPC/GET, qui est la possibilité à  partir de JSON-RPC 1.1 d'appeler une procédure d'un WebService JSON-RPC en GET au lieu d'en POST -- ce qui n'est possible que pour les procédures idempotentes (à  cause du cache implicite) et compatibles avec GET (prenant comme paramètres des types simples comme string et number, pas object) donc pas toutes ça dépend du WebService alors que pour du POST ça marche pour tout y'a pas de restriction -- mais vu qu'ils passent un paramètre "method=" suivi des paramètres, faut que je vérifie la RFC JSON-RPC mais ça pourrait bien en être (du JSON-RPC utilisé en mode GET au lieu de POST)

    Du coup si c'est le cas ça veut dire que rien ne nous empêche d'utiliser mon framework pour taper dans l'API FlickR, puisque toute méthode [d'un WebService JSON-RPC implémenté selon la norme 1.1 ou supérieur] pouvant être appelée en GET peut l'être également en POST (alors que l'inverse est faux mais bon). Le tuto appelle l'API en GET, mais parce que c'est plus simple pour lui (il met l'URL en dur dans sa NSURLRequest plutôt que construire son POST body)

    Bon à  tester faudrait que je regarde la doc de l'API FlickR, mais bon, ça y ressemble quand même. Ou alors ils ont fait un truc ressemblant à  du JSON-RPC pour tromper l'ennemi, c'est possible aussi ^^
  • AliGatorAliGator Membre, Modérateur
    11:22 modifié #6
    [EDIT] Bon j'ai rien dit, d'après la doc de l'API on peut l'attaquer en REST (avec un paramètre "method=", ce qui finalement ressemble un peu beaucoup à  du JSON-RPC appelé en GET, mais bon), en XML-RPC, ou en SOAP... mais pas JSON-RPC... bizarre...

    Pour en revenir au tuto, en plus de ta remarque sur la mauvaise delegate method utilisée, je viens de voir qu'ils n'encodait même pas ses valeurs GET avec des percent escapes dans sa requête, encore un truc foireux...
  • PierrePierre Membre
    11:22 modifié #7
    @Aligator & @zoc : si vous pensez pouvoir me trouver un meilleur tutos je suis preneur. ;) Je fait avec ce que je trouve et ma compréhension du code.

    @AliGator : je n'utilise pas ton framework car je suis incapable de le comprendre et de l'utiliser. Je ne sait pas par quel bout prendre le problème pour mettre en oeuvre ton framework lors d'un appel à  mon API. Peut être qu'avec des exemples d'utilisation j'arriverais à  mieux comprendre ce que tu a fait. ;)

    Merci pour vos retours,
    Pierre
  • AliGatorAliGator Membre, Modérateur
    juin 2010 modifié #8
    dans 1275467089:
    @AliGator : je n'utilise pas ton framework car je suis incapable de le comprendre et de l'utiliser. Je ne sait pas par quel bout prendre le problème pour mettre en oeuvre ton framework lors d'un appel à  mon API. Peut être qu'avec des exemples d'utilisation j'arriverais à  mieux comprendre ce que tu a fait. ;)
    HEIN ?!  >:( Moi qui ai pris pas mal de temps à  me faire ch...r à  faire une documentation aux petits oignons, super paufinée, documentant tout, et surtout avec une panacée d'exemples d'utilisation dans différents cas.... t'as toujours pas ton bonheur avec ça ?? ???

    • Télécharges mon framework, dedans tu as un dossier "Documentation" qui contient le docset avec tout plein de doc :
      • La documentation de chaque classe de mon framework, à  quoi elle sert, la documentation de chaque méthode, ... (un peu comme les docs "Class References" Apple)
      • Mais sinon la page d'accueil de la doc est un point d'entrée vers plein de pages d'explications, d'exemples, etc... qui expliquent les principes de base et comment se servir du framework (un peu comme les "Programming Guides" Apple)
      • Bref, parcourres la doc avant de dire un truc comme ça stp

    • Sinon tu peux aussi parcourir les pages du wiki de mon github, qui résument également comment utiliser mon framework, c'est un peu moins détaillé que ce qu'il y a dans le docset mais t'as déjà  tout ce qu'il faut comme bases pour te faire une idée de comment l'utiliser avant même d'avoir téléchargé le framework pour ouvrir le docset. Ce wiki contient également les explications des principes de base ET des exemples d'utilisation également...
    • Et sinon quand tu télécharges le framework, tu as aussi un projet d'exemple de fourni !!


    Avec tout ça et tout le temps que j'ai passé à  faire la doc pour faire un truc super documenté et clair et plein d'exemples de partout, et tout, si tu reviens me dire que tu ne sais pas par quel bout prendre le problème et que tu veux encore d'autres exemples alors que j'en ai déjà  un paquet de fourni dans ma doc... je sais plus quoi faire là  ! :(
  • PierrePierre Membre
    11:22 modifié #9
    @AliGator : je te promet que j'ai ouvert le projet de test, je l'ai compilé sur le simulateur, j'ai regardé le code, j'ai même ouvert la documentation.  ;)

    Mais pour moi cela reste du chinois. Je ne dit pas que tu n'as pas fait un boulot formidable, je dit juste que pour le moment je suis incapable de le comprendre.

    J'ai même été sur : http://www.raboof.com/Projects/Jayrock/Demo.ashx pour essayer de faire un rapprochement entre le code JSON produit et ce qui est affiché dans l'application de test.
    Mais je n'arrive pas à  générer le code JSON (je ne voit pas comment lui envoyer des paramètres, j'ai essayé : http://www.raboof.com/Projects/Jayrock/Demo.ashx?echo=test mais ça ne fonctionne pas).

    Pour moi un tutos comme celui donné en début du thread est compréhensible car je peut le suivre pas à  pas et décortiquer les sources du projet donné à  la fin. Mais ton framework je ne suis pas sur qu'il soit accessible à  un développeur débutant.

    Je te donne mon point de vue, je me suis sûrement mal exprimé dans mon post précédant. :)

    Pierre
  • AliGatorAliGator Membre, Modérateur
    11:22 modifié #10
    Bah justement t'as pas à  te soucier du JSON avec mon framework.
    Toute la mécanique de passage des paramètres, dans le corps POST de la requête HTTP, formatté en JSON, et tout, la partie prise de tête quoi surtout pour qui ne connait pas JSON-RPC... bah t'as pas besoin de t'en soucier.

    Tu fais juste
    NSURL* url = [NSURL URLWithString:@&quot;http://www.raboof.com/Projects/Jayrock/Demo.ashx&quot;];<br />JSONRPCService* service = [JSONRPCService serviceWithURL:url version:JSONRPCVersion_2_0]; // je crois que ce service est un WebService JSON-RPC version 2.0, à  vérifier dans la doc du WebService<br />[service callMethodWithName:@&quot;echo&quot; parameters:mkArray(@&quot;test&quot;)];<br />// ou au choix<br />[service callMethodWithNameAndParams:@&quot;echo&quot; , @&quot;test&quot; , nil];
    



    Après bien sûr certes y'a pas besoin de connaà®tre JSON ni JSON-RPC pour utiliser mon framework justement puisqu'il cache tout ça, mais faut juste quand même savoir ce qu'est un WebService, s'assurer que le WebService que tu veux attaquer a une API "JSON-RPC" (et pas SOAP ou XML-RPC ou autre), et consulter l'API dudit WebService pour avoir la liste des méthodes qu'il propose, et les arguments que prennent chacune de ces méthodes (genre ici une méthode "echo" avec un paramètre de type "string" entre autres)

    Là  encore suffit de lire la doc/API du WebService, sur la page du WebService en question http://www.raboof.com/Projects/Jayrock/Demo.ashx tu as justement la description du WebService avec la liste des méthodes, leurs arguments, et ce que fait chaque méthode. Si tu attaques un autre WebService bah il suffit de lire l'API qui est fournie avec le WebService pour décrire ses méthodes, s'assurer que c'est bien un WebService JSON-RPC, mais à  part ça t'as rien d'autre à  connaà®tre de JSON ou RPC puisque mon framework te permet d'en faire abstraction et de t'éviter de te poser ces questions.


    Alors bien sûr, pour le cas de FlickR, il semble que leur API fasse tout (XML-RPC, SOAP, ...) sauf JSON-RPC donc bien sûr ce n'est pas le bon exemple :P
  • PierrePierre Membre
    11:22 modifié #11
    @AliGator : dans mon cas je développe aussi bien l'API (le web-service) que l'application iPhone.

    J'ai donc besoin de comprendre comment le framework appelle l'API, et comment renvoyer mon JSON pour qu'il soit compris correctement.  :)

    Ensuite en quoi ton framework est "mieux" que le framework utilisé dans le tutos que j'ai mis dans le premiers post du thread ? (je n'y connais pas grand chose c'est pour ça que je demande ^^).

    Merci encore pour tes explications,
    Pierre
  • AliGatorAliGator Membre, Modérateur
    11:22 modifié #12
    Alors oui si c'est toi qui développes le WebService, en effet, et que tu veux faire un WebService JSON-RPC du coup, oui il faut que tu sachez comment fonctionne JSON-RPC du coup en effet. Tu as toutes les infos sur le site officiel http://www.json-rpc.org


    Quoique, si tu utilises des frameworks également côté serveur, tu peux aussi te passer de rentrer dans le bas niveau. Par exemple pour mon projet actuel je sais que celui qui code la partie serveur utilise le Zend Framework (PHP). Du coup il code ses classes PHP5 côté serveur, avec ses méthodes prennant ses arguments, qu'il commente comme il faut, et c'est Zend qui se charge "d'exposer" cela pour que ça soit appelable en JSON-RPC c'est à  dire que tu puisses appeler tes méthodes à  distance depuis l'iPhone via un appel au WebService. Et du coup s'il est bon de savoir un minimum ce qu'est JSON, bah le reste de toute la mécanique lui il s'en fiche c'est Zend qui le fait.

    Après je ne sais pas ce que tu vas utiliser toi côté serveur. Si tu codes tout à  la main oui tu vas devoir mettre les mains dans le cambouis (en PHP, ou en Ruby, ou en ASP.NET ou en je-sais-pas-en-quoi-tu-codes-ton-serveur). Si tu utilises des frameworks tout faits ça te facilitera la vie. Mais de ce côté là , la partie serveur c'est pas trop ma spécialité donc bon je ne saurai t'en dire plus.

    Ceci dit sur le principe le JSON-RPC n'est pas compliqué : le WebService reçoit, via une requête HTTP POST classique, une chaà®ne représentant un objet JSON, qui décrit la méthode à  appeler et ses paramètres. Il exécute ladite méthode, et il retourne le résultat sous forme d'un autre objet JSON. Le format des objets JSON échangés (nom des champs utilisés, etc) est décrit dans les RFC et specs de JSON-RPC (et comme la norme JSON-RPC a été pensée pour être super simple et abordable, bah la spec tient en une page ça va lol)
  • PierrePierre Membre
    11:22 modifié #13
    Le framework côté serveur est Symfony, le service est codé à  la main en PHP.

    Voici une explication du fonctionnement de l'API :

    Chaque fonction est représenté par une adresse (URL1) de la forme :
    http://api/module/action/format/?parametre1=valeur1&parametre2=valeur2

    • api : adresse web de l'API. Par exemple : api.webservice.com
    • module : fonction de l'API qu'on souhaite appeler. Par exemple : " article ".
    • action : action que l'ont souhaite effectuer sur le module. Par exemple " add ".
    • format : format de retour des informations : XML ou JSON.
    • parametreX : paramètres permettant de données des informations complémentaire. Par exemple : " title ".
    • valeurX : valeur du paramètre. Par exemple : " titre de mon article "


    L'exemple utilisé s'écrit :

    http://api.webservice.com/article/add/xml?title=titre de mon article
    Et permet l'ajout d'un article ayant pour titre : " titre de mon article ".


    Je ne pense pas supporter JSON-RPC. C'est pour ça que c'est sûrement plus simple pour moi d'appeler mon API directement avec une adresse et de parser le JSON qui m'est renvoyé. Tu en penses quoi ?

    Pierre
  • AliGatorAliGator Membre, Modérateur
    11:22 modifié #14
    En effet, vu la description que tu en fais, ce n'est pas du tout du JSON-RPC.
    Cela ressemble plutôt éventuellement à  du REST  (je connais pas toutes les specs par coeur du REST mais en tout cas si ça n'en n'est pas ça s'en rapproche fortement).

    Le REST étant un une façon de communiquer avec un WebService au même titre que SOAP, JSON-RPC ou XML-RPC, mais chacun est différent dans son format. Donc là  si tu as du REST (XML-REST ou JSON-REST puisqu'avec ton paramètre "format" tu peux choisir) le RPC n'intervient pas.

    Et du coup je ne sais pas (faut chercher sur github ou autre) s'il existe des frameworks iPhone pour faire du REST, qui se chargent d'encoder les paramètres GET comme il faut avec les urlencodes, récupérer la réponse, la parser, et tout... et si c'est pas le cas il faudra refaire tout ça à  la main (bon avec SBJSON pour parser le JSON mais ça c'est pas méchant, y'a juste 2 méthodes une pour transformer un NSArray ou NSDictionary en sa représentation JSON (une chaà®ne), l'autre pour faire l'inverse, chaà®ne JSON vers object Cocoa...
  • PierrePierre Membre
    11:22 modifié #15
    Je le fait déjà  à  la main aujourd'hui et ça marche plutôt bien. :)

    J'ai commencé avec un parser XML et j'avais un code lourd et non générique, avec SBJSON mon code est beaucoup plus léger et générique. :)

    Pierre
Connectez-vous ou Inscrivez-vous pour répondre.