asynchrone sans état API

Question

Imaginez une vue de table répertoriant certaines recettes. Chaque fois que l'utilisateur appuie sur une recette, une nouvelle vue de table est chargée pour répertorier les ingrédients de la recette.

Pour obtenir les informations, je suis asynchrone appeler une API REST en utilisant:

NSURLRequest *request = [NSURLRequest requestWithURL:url 
             cachePolicy:NSURLRequestReloadIgnoringLocalCacheData 
             timeoutInterval:30]; 

Lorsque les robinets utilisateur sur une recette, un appel à l'API est faite pour obtenir des ingrédients de la recette. Cependant, une fois dans la nouvelle vue (qui liste les ingrédients) et avant que la réponse soit reçue, l'utilisateur peut revenir en arrière et sélectionner une nouvelle recette.

Dans ce cas, je vais recevoir deux réponses; un pour chaque demande. Le problème est que je ne sais pas à quelle demande est cette réponse et je vais rafraîchir l'interface utilisateur avec un mauvais contenu d'une mauvaise réponse.

Je ne sais pas quelle est la bonne approche dans ce cas. Je pense à inclure dans la réponse chaque paramètre de demande. Donc, si je suis, par exemple, en utilisant l'API pour rechercher certains termes, nous disons « foo », je vais inclure le terme dans la réponse aussi, par exemple:

Demande:

http://domain.com/api/search?term=foo

réponse

{ 
"requestType": "search", 
"term": "foo", 
"result" : "a foo result" 
} 

il me semble étrange d'inclure chaque paramètre de demande chaque réponse, mais elle est la seule solution que je trouve à crea une API apatride prête à être appelée asynchrone.

¿Y a-t-il un autre moyen d'accomplir cela?

(J'utilise un modèle de délégué assignant un objet à chaque requête qui est appelée quand la réponse est reçue Le problème est, dans l'exemple des recettes, que la vue de table d'ingrédients est réutilisée chaque ingrédient de recette de temps).

Answer 1

Une possibilité consiste à inclure un "ID de requête" unique dans la requête, et au serveur de l'afficher en écho. Ensuite, le serveur n'a pas besoin de retourner tous les paramètres de la requête, juste l'ID de la demande. Le client générerait un nouvel identifiant pour chaque requête, en utilisant éventuellement quelque chose d'aussi simple que l'incrémentation d'un entier.

Une autre possibilité consiste à créer une "requête asynchrone annulable". Lorsque vous émettez la demande, renvoyez un objet qui peut être utilisé pour annuler la demande. Si la demande est annulée avant que le délégué ne soit déclenché, assurez-vous que le délégué ne sera pas renvoyé. Quand une réponse revient pour une demande annulée, il suffit de la jeter. Pour votre table d'ingrédients, avant d'émettre une nouvelle demande, vous annulez toute demande en attente (de sorte que vous ayez au plus une requête non annulée à la fois).

Une manière d'implémenter ceci consiste à créer un rappel en deux étapes. Le premier rappel, géré par l'infrastructure, vérifie simplement si la requête a été annulée. Sinon, il appelle le second rappel (qui est en fait votre délégué).

Answer 2

Une approche typique consiste ici à affecter une unique valeur unique (une valeur "clé") à chaque recette et à la renvoyer sur la réponse, un peu comme vous l'avez proposé. La valeur de la clé peut être le nom de la recette si elle est unique et courte, mais la stratégie la plus courante consiste simplement à utiliser un nombre unique ou une autre valeur sans signification pour l'utilisateur, mais sert à identifier une recette de façon unique même si (par exemple exemple) le nom change.Dans le jargon de la base de données, c'est la différence entre une clé business et une clé de remplacement . Les deux sont des identificateurs uniques, mais la clé métier a un sens pour un utilisateur (par exemple un nom) alors qu'une clé de substitution ne le fait pas. Ma recommandation est d'utiliser une clé de substitution parce que vous pouvez la raccourcir et elle n'aura jamais besoin de changer parce que l'utilisateur s'en fout. Notez que si vous acceptez une clé en tant que paramètre dans l'un de vos appels de service Web, vous devez la valider (ou la chiffrer si la sécurité est un problème), car vous ne savez jamais si le client l'altèrera. En passant, je fais ici l'hypothèse que le client "sait" quelle recette a été sélectionnée le plus récemment, donc il peut ignorer les réponses pour d'autres recettes.