J'écris une API apatride. Vous l'envoyez un document, il traite le document, puis renvoie le document traité. J'ai du mal à comprendre comment s'applique les règles reposantes. Je ne récupère pas de données, créant des données ou mettez à jour des données sur le serveur. Il n'y a pas de données sur le serveur. Que dois-je utiliser dans ce cas comme méthode HTTP et pourquoi?
3 Réponses :
Beaucoup de façons de faire ce que vous voulez. Mais voici une petite directive.
Je créerais un point final qui reçoit le document: / réception_document avec une méthode 'post'. Puisque vous êtes "envoyé" votre document au serveur
Je créerais un point de terminaison qui sert le document traité: / traitement_document avec une méthode 'get'. Puisque vous voulez récupérer / voir votre document du serveur?
N'est-il pas possible d'envoyer le document et d'obtenir la réponse dans une transaction HTTP? Sinon, le documentait doit être stocké quelque part ...
bien sûr possible. Il suffit d'utiliser la poste alors. et renvoyez le document traité de la manière dont vous voulez.
Bonne nouvelle - vous avez raison que c'est déroutant.
Rien sur le serveur ne change en réponse à la demande. Cela suggère que la demande est Safe . Donc Get est le choix naturel ici ... mais - obtenir Ne prend pas en charge les charges utiles de messages
Une charge utile dans un message de demande d'obtention n'a aucune sémantique définie; L'envoi d'un organisme de charge utile sur une demande d'obtention peut entraîner des implémentations existantes de rejeter la demande.
Head , l'autre méthode de sécurité omniprésente, a la même chose problème (et ne convient pas lorsque vous souhaitez renvoyer un document dans tous les cas).
La chose directe à faire à ce stade est simplement d'utiliser
post . Il est important de réaliser que POST ne promette pas qu'une demande est dangereuse, seulement qu'elle ne promett-elle pas que ce soit Safe - les composants génériques ne sauront pas que la demande est sûre et gagnée 't être capable de profiter de cela.Une autre possibilité est de regarder via le Registre de la méthode , Pour voir si quelqu'un a déjà spécifié une méthode qui a la sémantique que vous souhaitez. Les candidats incluent la recherche et le rapport, à partir des spécifications WebDAV. Ma lecture de ces spécifications est qu'ils n'ont pas réellement la bonne sémantique pour votre cas.
Le problème que vous essayez de résoudre concerne principalement la taille du document et le délai de traitement avant de renvoyer la réponse.
Théoriquement, afin d'utiliser une approche reposante, vous avez un point de terminaison, comme votrehost.com/api/document-manager (il peut s'agir d'un script PHP, ou tout ce que vous utilisez comme backend).
OK, donc au lieu de nommer le point final différemment pour chaque type d'opération, vous pouvez simplement modifier la méthode HTTP, je vais essayer de faire un exemple:
Poste: Utilisé pour télécharger le document, renvoie 200 OK lorsque le téléchargement est terminé.
Obtenir: renvoie le document traité, vous pouvez également renvoyer un code HTTP différent, au cas où le document n'est pas prêt ou même différent si le document n'a pas été téléchargé. 204 Aucun contenu ou 412 La condition préalable a échoué peut être de bons candidats en cas de document indisponible. Je ne suis pas sûr de la 412, on dirait que c'est renvoyé lorsque vous passez une en-tête dans la demande, indique au serveur quelle ressource retourner. Dans votre cas, je pense que l'utilisateur traite un document à l'heure. Mais pour faire une API plus solide, vous pouvez peut-être renvoyer un jeton d'identifiant à l'utilisateur, dans la réponse postale, puis transmettre ce jeton à la demande d'obtention, le serveur peut donc savoir exactement quel fichier l'utilisateur demande. < / p>
Mettre: Cette méthode doit être utilisée lors de la mise à jour d'une ressource déjà créée avec POST
Supprimer: supprime une ressource, puis retourner 204 ou 404
Options: La réponse contient les méthodes autorisées sur ce noeud final. Vous pouvez l'utiliser pour savoir par exemple quels privilèges ont l'utilisateur actuellement enregistré sur une ressource.
Head: est identique à un appel de get, mais cela ne devrait pas retourner le corps de réponse. C'est un autre bon candidat à votre connaissance lorsque le document a été traité. Vous pouvez télécharger avec le message, puis lorsque le téléchargement est effectué, commencez par écraser le même point d'extrémité avec le procédé de tête, enfin lorsqu'il retournera «trouvé», le sondage s'arrête et effectuera le dernier appel de get, ce qui sera Commencez le téléchargement du document traité.
Les méthodes HTTP sont une manière nette de gérer les communications HTTP, si elles sont utilisées correctement sont la voie à suivre et facilement compréhensible par d'autres développeurs. Et ne pas oublier, vous n'avez pas à inventer beaucoup de noms différents pour vos points d'extrémité, on suffit.
J'espère que cela vous a aidé un peu ... mais il y a beaucoup de guides sur le net. Au revoir!
Merci beaucoup @benz Benz. Si je peux choisir votre cerveau un peu plus, vos descriptions suggèrent que le processus serait 1) Publier le document, 2) Sondage avec la tête jusqu'à ce qu'il soit terminé 3) Obtenez quand il est terminé. Je ne veux évidemment pas persister le document traité à une DB. Alors cela va-t-il s'asseoir en mémoire sur le serveur en attendant le get? Et si le get ne vient jamais? Comment cela se compare-t-il à l'affichage ou à la sortie, puis à envoyer le document traité dans la réponse (ce que je pensais être le mieux initialement)? (Temps de calcul ~ 2 secondes, taille de document ~ 20kb, une à la fois). Merci encore.
Bonjour Mate, s'il vous plaît pouvez-vous partager un peu plus sur ce que vous devez accomplir? Peut-être avec des informations de fond que je peux vous donner une meilleure suggestion! Dis-moi aussi s'il vous plaît ce que vous utilisez comme backend and frontend (.. tous les cadres?). Et pourquoi vous souhaitez éviter de sauvegarder le fichier sur le serveur? Tout dépend de quel type de traitement que vous devez faire sur le document ... Si c'est quelque chose de simple, vous pouvez peut-être utiliser simplement JavaScript et déléguer le travail au navigateur du client ... Économiser des ressources sur le serveur!
J'utilise Python avec le cadre de repos Django. J'écris un moteur de recherche (à partir de zéro) et ce service est destiné à "normaliser" le document -> Compte tenu d'une chaîne de texte, supprimez les mots butées, la tige, les minuscules, etc. Il doit être un service car il est exécuté sur les deux les documents indexés et les requêtes utilisateur. Donc, je veux pouvoir dire au serveur, analyser ceci: '{"Texte": "Certains trucs textuels bruts"} "et récupérent ceci:' {" traité ": [" SOM "," RAW ", "Texte", "STU"]} '.
Ma question de base est que j'envoie ces données dans une chaîne d'URL avec une demande d'obtention, puis obtenez la réponse directement à l'arrière, ou est-ce que je l'envoie avec une requête postale, puis a) le récupère immédiatement si possible ou b) comme vous suggérez, sondage puis récupérer.
Je pense que je n'ai pas la raison pour laquelle vous utilisez un service, mais peut-être que cela va trop de sujet. Si tel est principalement ce que vous faites, j'essaierais d'abord de le faire avec quelques javascript ... alors lorsque le traitement est effectué sur le client, effectuez un appel sur le serveur avec le message pour télécharger les données obtenues à partir du document.
Fondamentalement, j'ai plus d'un service existant qui nécessite cette fonctionnalité.
Eh bien, comme je l'ai dit à première instance, tout dépend de la taille maximale de ce document. Parlons-nous de kilo-octets ou de mégaoctets?
~ 20kb comme mentionné ci-dessus
Désolé j'ai raté cela auparavant. Dans ce cas, j'utiliserais la méthode postale et renvoie les données traitées dans la réponse du même appel HTTP. C'est l'approche la plus simple et la plus efficace également à mon avis. Cela ne prendrait pas plus de deux secondes pour compléter tout le processus que je pense.