Essayer de faire une requête POST avec RestKit et mapper la réponse aux données de base

Vlad – Tout d'abord, mettons en place une réponse à votre question initiale:

Je suppose que vous travaillez sur RestKit 0.20.0, mais connaissez les API RestKit 0.10.x et consultez des informations obsolètes. Le premier endroit que vous devriez utiliser est RKObjectManager.h – les en-têtes seront toujours à jour et contiendront des documents sur les methods disponibles. Ensuite, vous pouvez toujours afficher la dernière documentation générée à partir du code source sur le dernier site de documentation de l'API .

Ce que vous voulez faire ici, c'est créer un RKObjectRequestOperation :

 NSDictionary *dictionary = @{ @"firstParam": @(12345), @"secondParam": @"whatever"}; NSMutableURLRequest *request = [objectManager requestWithObject:nil method:RKRequestMethodPOST path:@"/whatever" parameters:parameters]; RKObjectRequestOperation *operation = [objectManager objectRequestOperationWithRequest:request success:^(RKObjectRequestOperation *operation, RKMappingResult *result) { NSLog(@"Loading mapping result: %@", result); } failure:nil]; 

Si vous essayez de cibler datatables de base, alors vous voudrez utiliser RKManagedObjectRequestOperation et managedObjectRequestOperationWithRequest:success:failure: Il existe d'autres exemples disponibles dans le file README.md sur le site Restithit Github et dans les documents d'en-tête, ainsi qu'une tonne mésortingque de code dans les tests unitaires pour reference.

Ensuite, en réponse aux commentaires de JRG-Developer:

Ahem, c'est une réponse vraiment terrible pour un certain nombre de raisons. (Disclaimer: Je suis le développeur principal de RestKit)

Tout d'abord, quelle version de RestKit utilisez-vous? Si vous utilisez une version récente (c'est-à-dire dans la série de versions préliminaires 0.20.x), les methods de chargement des collections d'objects ont été remplacées par de meilleurs noms: getObjectsAtPath: Ceci est entièrement documenté dans la documentation de l'API ( Making Requests by Path ) et dans le guide de migration de 0.10 à 0.20 .

Je soupçonne que le problème original provient de la reference à la documentation désuète avec le code récent.

Ensuite, la stack de technologies que vous recommandz est beaucoup plus compliquée à installer et à utiliser pour accomplir les mêmes choses que RestKit vous offre une fois que vous avez compris la bibliothèque.

Jetons un coup d'oeil à ce point par point:

1. AFNetworking

   • L'AFN est une excellente bibliothèque légère pour effectuer des opérations de réseau asynchronouss. Si vous considérez RestKit comme une boîte à outils contenant un certain nombre d'outils pour implémenter des API côté client, alors l'AFN est le marteau.
   • J'ai énormément de respect pour l'APN et dans RestKit 0.20.x, nous avons timeoutssé notre bibliothèque de networking homebrewed vieillissante au profit d'AFNetworking parce que sa design était supérieure à la stack réseau personnalisée RestKit qui traîne depuis iOS 3.0. Cependant, l'APN ne vous fournit pas assez de puissance de feu pour implémenter complètement une API qui s'intègre aux données de base sans avoir une connaissance approfondie des données de base et implémenter vous-même une grande quantité de code de synchronisation.
   • Le système de mappage d'objects de RestKit vous fournit une API performante et cohérente pour configurer ces activités de synchronisation plutôt que de les implémenter vous-même. Cela permet des optimizations de performances sérieuses sur lesquelles je reviendrai plus tard.

2. JSONKit

   • JSONKit est une autre bibliothèque que je tiens en haute estime, mais cela ne vaut probablement pas votre time. Par rapport à NSJSONSerialization , la vitesse d'parsing JSON de JSONKit est supérieure – mais seulement en millisecondes.
   • En tant que personne ayant implémenté de grands clients API pour des applications largement déployées, je peux vous dire que votre time ne sera pas consacré à la serialization / déserialization JSON, mais au code qui traite votre JSON une fois désérialisé.

3. MagicalRecord

   • MagicalRecord est une bibliothèque de commodités de database qui fournit des accesseurs sténocharts pour les fonctionnalités existantes dans datatables de base. Cela ne va pas améliorer votre vie une fois que vous aurez compris tout ce qu'il faut pour implémenter un schéma de synchronisation HTTP vers Core Data. Vos problèmes n'auront rien à voir avec la syntaxe des requêtes de récupération des données de base étant trop verbeuse, il est incommode de conserver une reference à votre context d'object géré ou d'get la configuration de la stack de données de base.

Alors parlons des vrais problèmes avec l'implémentation d'une application iOS / OS X qui modélise une API dans Core Data pour un instant:

1. Accès asynchronous
   • Le premier problème que vous allez rencontrer est que vous avez l'habitude de programmer de manière synchrone, orientée thread principal, mais maintenant vous devez triggersr une requête AFNetworking qui charge votre JSON, mais ensuite le charger dans votre model object. Pas de problème, attendez que AFJSONRequestOperation vous renvoie dans le bloc de succès et mettez à jour Core Data, n'est-ce pas? Faux. Maintenant, vous effectuez vos E / S réseau de manière asynchronous, puis effectuez la tâche CPU intensive de mise à jour de votre model de données sur le thread principal. Maintenant, la performance de votre application est nulle et vous ne savez pas quoi faire à ce sujet. Comment déplacez-vous cette synchronisation en arrière-plan? Comment notifiez-vous l'interface user une fois que c'est fait?
2. La gestion des erreurs
   • Que se passe-t-il lorsque vous rencontrez une erreur? Que faites-vous lorsque vous obtenez une erreur réseau? Que faites-vous lorsque l'opération réseau est terminée, mais que vous avez rencontré une erreur lors de l'access aux données de base? Comment allez-vous le gérer? Allez-vous mettre ce code de gestion des erreurs dans tous vos controllers? Comment allez-vous encapsuler toute cette logique?
   • Comment allez-vous gérer les erreurs renvoyées par votre server?
3. Identification d'object unique
   • Bon alors maintenant vous avez chargé votre JSON et vous voulez le mettre dans datatables de base. Génial. Comment allez-vous différencier les objects existants dans le magasin par rapport aux nouveaux qui doivent être créés?
   • Si vous vous trompez, vous avez maintenant des objects en double.
   • Si vous obtenez ce droit, mais le faire à partir d'un context de thread principal, votre interface user est bloquée et votre performance est nulle.
   • Si vous obtenez ce droit, mais le faire sur un thread d'arrière-plan, vous pouvez avoir des problèmes de concurrency.
   • Si vous avez raison, mais que vous accédez au magasin persistant avec des requêtes d'extraction pour identifier vos objects uniques, vous avez maintenant des problèmes de performance.
4. Suppression d'objects orphelins
   • Une fois que vous avez synchronisé votre set de données avec le server, comment allez-vous prendre soin de supprimer les objects morts du magasin local qui n'existent plus sur le server?
5. Performance
   • Comme je l'ai déjà mentionné dans plusieurs parties de cette diasortingbe, toutes les routes mèneront à la performance. Si vous essayez réellement de build quelque chose qui fonctionnera et ravira les users sur une grande échelle, vous allez devoir faire face à de sérieux problèmes de performance. Hue.

Il y a un certain nombre de problèmes supplémentaires auxquels vous devrez faire face une fois votre application réussie, y compris la testabilité, la maintenabilité, etc. À quel point pensez-vous à ces choses?

Je pense que mon point principal est que c'est (de mon sharepoint vue) beaucoup trop commun pour entendre des acclamations ou des railleries venant de la galerie d'arachides sur la façon de résoudre les problèmes d'ingénierie fondamentaux. La réalité est que la solution aux problèmes de complexité essentielle aura une courbe d'apprentissage relative à celle du problème à aborder.

Il est de loin, beaucoup plus facile de prendre une part discrète de la fonctionnalité et de find une solution satisfaisante que d'essayer d'aborder un problème plus grand, mais plus intéressant.

Mais cela ne signifie pas que vous allez produire une solution plus robuste en rassemblant un tas de bibliothèques que vous avez entendues fournir de bonnes implémentations d'un sous-set d'un problème qu'une approche plus large du problème global.

Pourquoi personne n'a-t-il ouvert son propre mashup AFN / JSONKit / Core Data / MagicalRecord et soufflé RestKit hors de l'eau s'ils sont tellement mieux que RestKit?

J'ai peur que la vérité sobre soit: ce n'est pas si facile.

À votre santé!