Héberger des opérations de service Web à exécution longue durée

Question

Je crée un service Web pour gérer le traitement de fichiers (ce qui peut prendre beaucoup de temps) et j'essaie de le tester à l'avenir en m'assurant que le serveur Web ne se retrouve pas avec trop de fichiers en mémoire à la fois.

Pour ce faire, je permets à un utilisateur de télécharger le fichier, je le mets immédiatement dans le stockage blob Azure et lui donne un ID pour ce fichier. Pendant ce temps, le fichier a été ajouté dans une file d'attente de traitement en arrière-plan (manipulé par une application distincte) qui, une fois terminé, ajoute le fichier de sortie dans azure et met à jour la base de données pour refléter l'opération terminée. Ce que je m'attends à ce que l'utilisateur fasse est d'utiliser l'ID que je leur ai donné au moment où ils ont téléchargé le fichier avec succès, pour appeler le service web pour dire "Est-ce que mon fichier est prêt? pour moi".

Est-ce une pratique acceptable? Au début, je l'avais pour que l'utilisateur ait à attendre la fin de toute l'opération, ce qui était beaucoup plus propre, mais j'avais l'impression que cela n'allait pas très bien. Ce que je pensais, c'est que si je sépare le composant de traitement de fichiers de la requête, et que le fichier passe dans une file d'attente de traitement, il peut être traité immédiatement, mais cela peut aussi prendre plusieurs minutes. le service Web obtient - pire scénario, cela pourrait prendre des heures si je n'implémente pas la mise à l'échelle automatique), et j'étais préoccupé par le fait de laisser traîner une requête web pendant très longtemps. Est-ce que je suis trop ingénieur ou est-ce une approche raisonnable?

Answer 1

Cette approche est très sensée. En fait, REST répond spécifiquement à cela avec le code de réponse 202 Accepted.

Voir Asynchronous REST pour plus de détails.

Pour résumer:

1. lorsque l'utilisateur soumet la demande initiale, ne leur donnez pas seulement un ID pour le fichier, le code d'état de retour 202 Accepted et définissez l'en-tête d'emplacement à l'URI d'une ressource temporaire qu'ils peut interroger pour obtenir demande d'état
   1. le corps à cette ressource temporaire peut contenir l'ETA jusqu'à la fin, ou tout simplement qu'il est « en cours »
2. Lorsque la demande est comp leted, cet URI doit renvoyer 303 See Other avec l'en-tête Location défini sur l'URI où il peut réellement obtenir le fichier.