Nous construisons un service de repos qui prendra environ 5 minutes à exécuter. Ce ne sera appelé que quelques fois par jour par une application interne. Existe-t-il un problème à l'aide d'une demande de repos (IE: http) qui prend 5 minutes à compléter?
Devons-nous nous soucier des délais d'expiration? Devrions-nous commencer la demande dans un fil séparé sur le serveur et avoir le sondage client pour le statut?
4 Réponses :
Si Gardez à l'esprit que si vous avez quelques pare-feu entre vous pourriez avoir des connexions de goutte si elles sont inactives depuis un certain temps.
Pourrais-je suggérer d'enregistrer une procédure "rappel"? Le client émet la demande avec un «point de terminal de rappel» sur le serveur, obtient un «billet». Une fois le serveur terminé, il "rappel" le client ... ou le client peut vérifier l'état de la demande via l'identifiant de billet.
supposant que vous puissiez configurer les délais d'attente HTTP à l'aide du cadre que vous choisissez, vous pouvez alors demander via un get et juste accrocher pendant 5 minutes.
Cependant, il peut être plus flexible d'initier une exécution via un post, obtenez un reçu (un numéro / ID quoi que ce soit), puis effectuez une utilisation d'une utilisation de 5 minutes plus tard (et peut-être réessayer que votre procédure ne prendra pas exactement 5 minutes à chaque fois). Si la demande est toujours en cours, renvoyez-vous un code d'erreur HTTP approprié (404 peut-être, mais que reveniez-vous pour obtenir un reçu non existant?) Ou renvoyez les résultats si disponible.
N'est-ce pas l'état (sur le serveur) et n'est-ce pas un comportement remarquable contre les idéaux de repos?
@Merlyn Morgan-Graham: Ce n'est pas une sottise qui est "contre les idéaux de repos", c'est l'état caché. Étant donné que l'état est disponible en tant que ressource à une URL donnée, c'est bien.
Ceci est une approche.
Créer une nouvelle demande d'exécution ProcessXYZ P>
GET /ProcessXYZRequests/Pending GET /ProcessXYZRequests/Completed GET /ProcessXYZRequests/Failed GET /ProcessXYZRequests/Today
Comme Brian Agnew souligne, à 5 minutes est tout à fait gérable, si un peu du gaspillage des ressources, si l'on peut contrôler les paramètres de délai d'attente. Dans le cas contraire, au moins deux demandes doivent être faites: Le premier à obtenir le processus de production de résultats de roulement, et le second (. Et troisième, quatrième, etc , si le résultat est plus long que prévu à la compilation) au vote pour le résultat.
Brian Agnew et Darrel Miller deux suggèrent des approches similaires pour les deux (+) - approche étape: POST une requête à un paramètre d'usine, en commençant un travail sur le serveur, puis obtenir le résultat du point final de résultat retourné
Alors que ce qui précède est une solution très courante, et adhère bien à la lettre des contraintes de repos, il sent très bien de RPC. Autrement dit, plutôt que de dire « me fournir une représentation de ce ressource », il dit « exécuter ce emploi » (RPC), puis « me fournir une représentation de la ressource qui est le résultat de l'exécution du travail »(REST). EDIT: Je parle très vaguement ici. Pour être clair, rien de tout cela défie toute explicitement les contraintes REST , mais il ne ressemble très bien habiller une approche non RESTful dans les vêtements de REST, perdant sur ses avantages ( par exemple la mise en cache, idempotence) dans le processus.
En tant que tel, je préfère penser que lorsque les clients premières tentatives pour la ressource, le serveur doit répondre avec 202 « Accepté » ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 ), peut-être « réessayer en 5 minutes » quelque part dans l'entité de réponse. Par la suite, le client peut interroger le même point final pour obtenir le résultat, le cas échéant (sinon retourner une autre 202, et réessayer plus tard).
Quelques avantages supplémentaires de cette approche sont que les ressources à usage unique (comme les emplois) ne sont pas inutilement créés, ne doivent pas être interrogés deux points d'extrémité séparés (usine et résultat), et même le second besoin de point de terminaison ne sont pas déterminées à partir de l'analyse de la réponse de la première, donc plus simple. De plus, les résultats peuvent être mises en cache, « gratuitement » (sage code). Réglez l'heure d'expiration du cache dans l'en-tête de résultat selon combien de temps les résultats sont « valides », dans un certain sens, pour votre domaine de problème.
Je souhaite que je pourrais appeler cela un exemple de manuel d'une approche « axée sur les ressources », mais, peut-être ironiquement, le chapitre 8 du « RESTful Web services » indique les deux-point final, l'approche de l'usine. Go figure.
C'est intéressant, merci encore de partager. J'ai peut-être besoin de penser plus à ce sujet, mais au sommet de ma tête, un inconvénient que je vois à l'approche du point d'extrémité unique serait que l'on souhaiterait définir une durée de cache à temps fixe, ce qui signifierait que "réessayer" la Toute opération avant l'expiration du cache n'entraînerait pas une tentative réelle. Dans certains cas d'utilisation, cela pourrait confondre les utilisateurs