Hum d'accord, ne connaissant pratiquement pas JSON (je m'en sers juste pour remplacer mes XML) j'avoue ne pas trop voir comment ça peut fonctionner tout ça. Merci en tout cas.
JSON est facile à apprendre (bon framework Cocoa et côté serveur c'est aussi assez facile à fabriquer des chaà®nes JSON).
Le plus compliqué c'est de traiter le RPC côté serveur... du coup ça m'a un peu refroidi et j'envisage plutôt HTTP POST + ASIHTTPREQUEST + (JSON ou PLIST cf discussion Yoann).
Alors c'est comme toi que j'envisageais la chose. Quand tu parles de HTTPPOST c'est du php qui traite tes ordres envoyés? Et ASIHTTPREQUEST c'est quoi?(je suis en voiture pas facile d'aller voir;) )
ASIHTTPREQUEST est un framework qui simplifie les connexions réseaux et requêtes entrantes/sortantes, gérant aussi des queues de requêtes... La doc est bonne. Je le conseille.
Côté serveur c'est ce que tu veux... (PHP, ruby, java...) que soit du RPC ou du HTTP "classique".
Alors comme l'a relevé zoc, mon projet utilise SBJSON (et l'encapsule de sorte que ce soit justement transparent pour toi). Du coup les quelques essais de code que tu as fais avec SBJSON, tu n'auras plus à le faire car mon framework fait l'appel à cette partie-là ... entre autres choses.
En fait mon framework se charge de :
Encapsuler l'appel d'une méthode de ton WebService JSON-RPC (que tu vas coder en Ruby ou PHP ou ce que tu veux ça c'est pas mon affaire :P), en prenant le nom de la méthode, les paramètres d'appel de la méthode, etc, en transformant tout ça pour que ça fasse du JSON formatté correctement pour suivre les normes d'un appel RPC
Envoyer la requête ainsi formée, avec tout ce qu'il faut (headers, contenu, etc), à ton WebService, et récupérer sa réponse (il encapsule les appels à NSURLRequest et NSURLConnection, etc. que tu n'as donc pas non plus à faire)
Vérifier qu'il n'y a pas eu de souci lors de cet envoi et attente de réponse (problème réseau, problème de parsing de la réponse renvoyée par ton serveur, erreur 404, ...) et si oui appeler une méthode de delegate pour te le signaler en encapsulant le tout dans une NSError, etc
Sinon, si tout se passe bien, récupérer la réponse JSON retournée, la parser, l'interpréter (extraire le résultat, l'erreur, etc...), et éventuellement la convertir dans l'objet Objective-C de ton choix (par défaut c'est juste le parsing de l'objet JSON, donc un NSDictionary ou un NSArray, comme le fait SBJSON c'est justement là qu'il est appelé... et mon framework te permet d'aller plus loin si tu veux en les convertissant en des classes perso genre Book par exemple, classe que tu as dans ton programme pour représenter un livre qui t'es retourné par ton WebService par exemple...)
appeler la méthode de delegate par défaut [tt]methodCall:didReturn:error:[/tt] (ou une autre si tu as demandé d'en appeler une autre que celle par défaut, ce qui peut être utile si tu fais plusieurs appels et utilise le même delegate pour tous) pour remonter le résultat ainsi parsé, interprété, et éventuellement converti, à ton delegate
Ainsi, avec tout ça, si tu veux appeler une méthode "getBooks" (sans paramètres, pour le coup) de ton WebService qui se situe disons à l'URL "http://www.ceetixlibrary.com"; et qui te permet, par exemple, de gérer les livres de ta bibliothèque, tu n'as qu'à écrire ces quelques lignes :
Et mon framework s'occupe du reste, formatage, envoi de la requête, récupération du résultat, parsing, etc... et toi tu n'as même plus besoin d'utiliser SBJSON directement, tu as juste à récupérer le résultat dans la méthode de delegate :
Et c'est tout pour le code iPhone Après le code du serveur, bah c'est pas mon problème (ni mon domaine), mais il existe des frameworks également (en Ruby, en PHP, ...) pour coder la partie serveur.
Perso mon framework n'utilise pas ASIHTTPRequest... surtout parce que je ne le connais pas (enfin il me semble avoir déjà vu le nom passer qqpart mais bon), et que je ne suis pas sûr qu'il m'apporte qqch (enfin qu'il faille l'inclure dans mon framework et donc de l'avoir dans tous les projets voulant utiliser AliJSONRPC alors que la seule communication entre votre appli et le serveur peut tout à fait être limitée à l'appel à votre WebService par l'intermédiaire de mon framework... qui se débrouille pour l'instant très bien sans ASIHTTPRequest, alors bon...)
JSON est facile à apprendre (bon framework Cocoa et côté serveur c'est aussi assez facile à fabriquer des chaà®nes JSON).
Le plus compliqué c'est de traiter le RPC côté serveur... du coup ça m'a un peu refroidi et j'envisage plutôt HTTP POST + ASIHTTPREQUEST + (JSON ou PLIST cf discussion Yoann).
c'est plutôt simple comme protocole JSON c'est simplement javascript pour la définition d'objet dans sa notation simplifié un objet JSON est une liste de clef valeur noté de la façon suivante
{} signifie objet chaque couple clef valeur est séparé par un , et la valeur de la clef est situé après : les type de base sont ceux de javascript donc number string boulean, null les tableaux sont des listes de valeur (quelque en soit le type)
tout cela se combine joyeusement. normalement JSON ne doit pas transporter de définition de fonction mais souvent dans les implémentation javascript on fait un eval à la place d'un parce du coup on vois parfois une fonction transiter ainsi (c'est dangereux) voilà pour la base
RCP est un protocole d'appel de procédure à distance. sa déclinaison en JSON est fort simple
utiliser un objet JSON pour transporter la requête et obtenir la réponse dans un objet JSON
excécuter la méthode nomDeLaMethode avec les paramètes [5, "test", [1,2], {"x":45, "y":12}] l'id est un identifiant que fournit le client pour sa requête le serveur lui enverra la réponse avec cet identifiant (cela permet de gérer les échange asynchrone avec des mode de transport relâche)
le protocole ne définit pas la méthode de transport souvent HTTP-POST parfois HTTP-PUT ou HTTP-GET mais on peut aussi avoir HTTP-CALL ou le verbe HTTP de sont choix (tout dépend des capacité du serveur HTTP) mais on peut aussi utiliser d'autre méthodes de transport SMTP par exemple le client envoie sa requête dans le corps d'un message ou en pièce jointe et le serveur lui réponds de la même façon. cette solution est pratique pour les mode relâchés. on peut aussi utiliser des sockets ou tout ce que vous pouvez imaginer pour transporter un paquet JSON (FTP, disque partagé, Bluetooth etc.)
il faut bien évidemment que le client et le serveur utilise le même mode de transport.
que ce soit côté serveur ou côté client il faut pour que ça fonctionne un outil de sérialisation et de dé-sérialisation. suivant le langage que l'ont utilise pour implémenter le client et/ou le serveur un va matcher les différents type de JSON dans le langage en question. souvent number => float (et int) string => string null => null ou nil suivant le langage [] => array {} => hashtable
lorsque le langage est dynamique (capable de définir des classes à l'exécution ou de définir des objet sans classe) {} est transformé en objet.
côté client construire un objet requête sérialiser la requête l'envoyer sur la couche de transport à la réception côté serveur (garder les référence du client pour lui répondre) dé-sérialiser la requête invoquer la méthode demandé en lui passant les paramètres récupérer la réponse construire un objet réponse le sérialiser le donner à la couche de transport (pour l'envoyer un bon client) à la réception de la réponse côté client dé-sérialiser la réponse utiliser l'objet réponse.
avec HTTP on ne peut pas se tromper de client mais avec d'autre couche de transport oui.
c'est donc relativement simple le client comme le serveur doivent être capable de gérer les erreurs liées au transport mais il peut y avoir des erreurs dans JSON-RPC lui même le paquet envoyé par le client n'est pas compatible JSON -32700 Parse Error la réponse est
le message est bien du JSON mais pas une requête RPC (method, params, id) -32600 Invalid Request le message est bien une requête JSON-RPC mais la méthode n'est pas connue du serveur -32601 Invalid Method le message est bien une requête JSON-RPC mais les paramètres sont incorrect ou absent (il ne s'agit pas ici de la vérification sémantique des paramètres mais syntaxique) -32602 Invalid Parameters tout est OK mais le serveur c'est planté -32603 Internal Error (celle là c'est dur dur) enfin tout est ok et la méthode s'exécute correctement mais le développeur de la méthode à prévu d'autre erreurs (sémantiques) par exemple getUserAdress avec un user inconnu. -32099 -32000 sont les erreurs que l'on peu utiliser.
cela fait 100 erreurs en tout c'est beaucoup et peu beaucoup car sur une méthode avoir 100 erreurs différentes possible c'est rare mais lorsqu'on a beaucoup de méthodes 100 erreurs c'est peu.
la encore c'est à l'implémentation du serveur qu'il faut faire ses choix.
si on à peut de méthodes un code par erreur les code sont donc unique et le traitement d'erreur coté client est simple si on a beaucoup de méthodes un code par erreur et par méthode on a donc des un traitement d'erreur qui tien compte du couple N° erreur méthode.
voilà pour le tour d'horizon
une note : non prévu dans dans le protocole mais pas interdit la notation des méthodes étant libre on trouve parfois des méthode noté ainsi userManager.setPostalAdress d'un point de vu purement RPC ceci est un appel de la méthode "userManager.setPostalAdress" souvent à l'implémentation cela correspond à l'appel de la méthode "setPostalAdress" sur l'objet "userManager"
Et pour information justement, tous ces aspects que tu as décrit sekajin, il est inutile normalement de les connaà®tre pour utiliser mon framework, puisque justement il se charge de tous ces aspects techniques, de la notation d'un objet JSON (et de l'encapsulation d'un objet Cocoa en JSON) à son évaluation/parsing en passant par le type d'objets à envoyer pour faire du JSON-RPC et le type de retour attendu etc. D'un point de vue de l'utilisateur de mon framework, donc du développeur iPhone qui veux appeler un WebService JSON-RPC quelconque (le sien perso qu'il a développé sur un site ou un WebService existant sur le net), mon framework permet de ne manipuler que des objets Cocoa, sans même savoir ce qu'il y a en dessous, à quoi ressemble le JSON, comment sont notés les objets JSON et les array JSON, la sérialisation, la couche transport utilisée (HTTP/POST, ...) : tout ça mon fmk permet d'en faire abstraction.
Après pour les curieux qui veulent plus d'infos sur json, il y a toujours json.org (qui montre à quel point JSON est simple), et json-rpc.org pour les specs JSON. Ca peut être utile si vous avez à développer la partie serveur (si le WebService que vous voulez appeler ça sera votre propre WebService sur votre site, à développer vous-même)... et encore, puisqu'il y a des frameworks tout faits côté serveur aussi (en standard en Ruby à ce que j'ai compris, ou Zend pour le PHP5, etc...)
Réponses
Le plus compliqué c'est de traiter le RPC côté serveur... du coup ça m'a un peu refroidi et j'envisage plutôt HTTP POST + ASIHTTPREQUEST + (JSON ou PLIST cf discussion Yoann).
Et ASIHTTPREQUEST c'est quoi?(je suis en voiture pas facile d'aller voir;) )
Côté serveur c'est ce que tu veux... (PHP, ruby, java...) que soit du RPC ou du HTTP "classique".
EDIT : Ali, désolé de pourrir ton thread. :-*
Du coup les quelques essais de code que tu as fais avec SBJSON, tu n'auras plus à le faire car mon framework fait l'appel à cette partie-là ... entre autres choses.
En fait mon framework se charge de :
Ainsi, avec tout ça, si tu veux appeler une méthode "getBooks" (sans paramètres, pour le coup) de ton WebService qui se situe disons à l'URL "http://www.ceetixlibrary.com"; et qui te permet, par exemple, de gérer les livres de ta bibliothèque, tu n'as qu'à écrire ces quelques lignes : Et mon framework s'occupe du reste, formatage, envoi de la requête, récupération du résultat, parsing, etc... et toi tu n'as même plus besoin d'utiliser SBJSON directement, tu as juste à récupérer le résultat dans la méthode de delegate : Et c'est tout pour le code iPhone
Après le code du serveur, bah c'est pas mon problème
Perso mon framework n'utilise pas ASIHTTPRequest... surtout parce que je ne le connais pas (enfin il me semble avoir déjà vu le nom passer qqpart mais bon), et que je ne suis pas sûr qu'il m'apporte qqch (enfin qu'il faille l'inclure dans mon framework et donc de l'avoir dans tous les projets voulant utiliser AliJSONRPC alors que la seule communication entre votre appli et le serveur peut tout à fait être limitée à l'appel à votre WebService par l'intermédiaire de mon framework... qui se débrouille pour l'instant très bien sans ASIHTTPRequest, alors bon...)
c'est plutôt simple comme protocole
JSON c'est simplement javascript pour la définition d'objet dans sa notation simplifié
un objet JSON est une liste de clef valeur noté de la façon suivante
{} signifie objet
chaque couple clef valeur est séparé par un ,
et la valeur de la clef est situé après :
les type de base sont ceux de javascript
donc number string boulean, null
les tableaux sont des listes de valeur (quelque en soit le type)
tout cela se combine joyeusement.
normalement JSON ne doit pas transporter de définition de fonction
mais souvent dans les implémentation javascript on fait un eval à la place d'un parce du coup on vois parfois une fonction transiter ainsi (c'est dangereux)
voilà pour la base
RCP est un protocole d'appel de procédure à distance. sa déclinaison en JSON est fort simple
utiliser un objet JSON pour transporter la requête et obtenir la réponse dans un objet JSON
excécuter la méthode nomDeLaMethode avec les paramètes [5, "test", [1,2], {"x":45, "y":12}]
l'id est un identifiant que fournit le client pour sa requête le serveur lui enverra la réponse avec cet identifiant
(cela permet de gérer les échange asynchrone avec des mode de transport relâche)
le protocole ne définit pas la méthode de transport souvent HTTP-POST parfois HTTP-PUT ou HTTP-GET
mais on peut aussi avoir HTTP-CALL ou le verbe HTTP de sont choix (tout dépend des capacité du serveur HTTP)
mais on peut aussi utiliser d'autre méthodes de transport
SMTP par exemple le client envoie sa requête dans le corps d'un message ou en pièce jointe et le serveur lui réponds de la même façon. cette solution est pratique pour les mode relâchés.
on peut aussi utiliser des sockets ou tout ce que vous pouvez imaginer pour transporter un paquet JSON (FTP, disque partagé, Bluetooth etc.)
il faut bien évidemment que le client et le serveur utilise le même mode de transport.
que ce soit côté serveur ou côté client il faut pour que ça fonctionne un outil de sérialisation et de dé-sérialisation.
suivant le langage que l'ont utilise pour implémenter le client et/ou le serveur
un va matcher les différents type de JSON dans le langage en question.
souvent number => float (et int)
string => string
null => null ou nil suivant le langage
[] => array
{} => hashtable
lorsque le langage est dynamique (capable de définir des classes à l'exécution ou de définir des objet sans classe)
{} est transformé en objet.
côté client construire un objet requête
sérialiser la requête
l'envoyer sur la couche de transport
à la réception côté serveur (garder les référence du client pour lui répondre) dé-sérialiser la requête
invoquer la méthode demandé en lui passant les paramètres
récupérer la réponse
construire un objet réponse
le sérialiser
le donner à la couche de transport (pour l'envoyer un bon client)
à la réception de la réponse côté client dé-sérialiser la réponse
utiliser l'objet réponse.
avec HTTP on ne peut pas se tromper de client mais avec d'autre couche de transport oui.
c'est donc relativement simple le client comme le serveur doivent être capable de gérer les erreurs liées au transport
mais il peut y avoir des erreurs dans JSON-RPC lui même
le paquet envoyé par le client n'est pas compatible JSON
-32700 Parse Error la réponse est
le message est bien du JSON mais pas une requête RPC (method, params, id)
-32600 Invalid Request
le message est bien une requête JSON-RPC mais la méthode n'est pas connue du serveur
-32601 Invalid Method
le message est bien une requête JSON-RPC mais les paramètres sont incorrect ou absent (il ne s'agit pas ici de la vérification sémantique des paramètres mais syntaxique)
-32602 Invalid Parameters
tout est OK mais le serveur c'est planté
-32603 Internal Error (celle là c'est dur dur)
enfin tout est ok et la méthode s'exécute correctement mais le développeur de la méthode à prévu d'autre erreurs (sémantiques) par exemple getUserAdress avec un user inconnu.
-32099 -32000 sont les erreurs que l'on peu utiliser.
cela fait 100 erreurs en tout
c'est beaucoup et peu
beaucoup car sur une méthode avoir 100 erreurs différentes possible c'est rare mais lorsqu'on a beaucoup de méthodes 100 erreurs c'est peu.
la encore c'est à l'implémentation du serveur qu'il faut faire ses choix.
si on à peut de méthodes un code par erreur les code sont donc unique et le traitement d'erreur coté client est simple
si on a beaucoup de méthodes un code par erreur et par méthode on a donc des un traitement d'erreur qui tien compte du couple N° erreur méthode.
voilà pour le tour d'horizon
une note :
non prévu dans dans le protocole mais pas interdit
la notation des méthodes étant libre on trouve parfois des méthode noté ainsi
userManager.setPostalAdress
d'un point de vu purement RPC ceci est un appel de la méthode "userManager.setPostalAdress"
souvent à l'implémentation cela correspond à l'appel de la méthode "setPostalAdress" sur l'objet "userManager"
A+JYT
D'un point de vue de l'utilisateur de mon framework, donc du développeur iPhone qui veux appeler un WebService JSON-RPC quelconque (le sien perso qu'il a développé sur un site ou un WebService existant sur le net), mon framework permet de ne manipuler que des objets Cocoa, sans même savoir ce qu'il y a en dessous, à quoi ressemble le JSON, comment sont notés les objets JSON et les array JSON, la sérialisation, la couche transport utilisée (HTTP/POST, ...) : tout ça mon fmk permet d'en faire abstraction.
Après pour les curieux qui veulent plus d'infos sur json, il y a toujours json.org (qui montre à quel point JSON est simple), et json-rpc.org pour les specs JSON. Ca peut être utile si vous avez à développer la partie serveur (si le WebService que vous voulez appeler ça sera votre propre WebService sur votre site, à développer vous-même)... et encore, puisqu'il y a des frameworks tout faits côté serveur aussi (en standard en Ruby à ce que j'ai compris, ou Zend pour le PHP5, etc...)