J'ai un cas d'utilisation où un contexte doit être transféré de l'interface utilisateur au backend et à la backend nécessaire pour décider et envoyer la réponse en fonction de ce contexte.
Ceci peut être obtenu en envoyant le contexte par le biais du corps de la demande et au niveau du serveur, en analysant le corps de la demande, la représentation peut être envoyée dans le corps de réponse.
mon doute est quelle méthode HTTP convient à cela?
Obtenez: Si nous utilisons GET, nous pouvons envoyer le corps de la demande, mais il est conseillé que l'organisme ne soit pas sépaantique lié à la demande.
Voir ceci: HTTP-GET-WIT-Demand-Body
Donc, je suis laissé avec la poste ou la mise, mais ceux-ci correspondent à la mise à jour ou à la création d'une ressource et à les utiliser peut être peu trompeur.
Donc, ma question est de savoir quelle est la méthode HTTP appropriée pouvant être utilisée dans ce scénario qui est acceptable dans le point de vue de la conception reposante.
Appréciez la réponse.
Je pense que je pense utiliser post ou mettre comme il n'y a pas de restrictions à consommer le corps de la demande du côté serveur.
Je pense que la poste servirait mon but.
Le RFC HTTP RFC 7231 dit que la poste peut être utilisée pour:
fournissant un bloc de données, tel que les champs entrés dans un formulaire HTML, à un processus de traitement de données
Le processus de traitement des données pour moi est le serveur de backend et le formulaire HTML équivalent à tout élément UI.
Donc, je peux utiliser la méthode postale pour envoyer les données à la backend et envoyer la représentation des ressources existante en tant que corps de réponse avec code d'état HTTP étant 200
4 Réponses :
J'irais pour Post car dans le reste, Met est utilisé pour créer une nouvelle ressource comme l'utilisateur.
Effectivement mettre l'opération est idempotent. Mise est utilisée pour créer si la ressource n'est pas présente d'autre pour mettre à jour la ressource. Mais de toute façon, merci pour l'entrée
Il existe un Patch Post Method, c'est-à-dire pour changer les choses peut-être que c'est ce que vous recherchez
En fait, je n'ai pas l'intention de changer de ressource, je souhaite plutôt décider de quelle représentation de ressources doit être envoyée du côté serveur, basée sur le corps de la demande. La ressource existe déjà sur le côté serveur
Connect est utilisé à proxy sur demande, et puisque vous envoyez des données en fonction de la demande de commission dans, le connectez en-tête mon être utile
Veuillez garder à l'esprit que Si l'opération est censée être idempotente, optez pour La méthode Mettez la méthode des requêtes que l'état de la ressource cible est créé ou remplacé par l'état défini par la représentation enfermée dans la charge utile de la demande. Un Sinon, allez pour La méthode POST Demandes que le processus de ressource cible La représentation conçue dans la demande en fonction de la sémantique spécifique de la ressource. [...]
obtenir doit être utilisé pour récupération de données uniquement , sans effets secondaires. C'est-à-dire que get est tous les deux coffre et idempotent (voir plus de détails ici ).
mettre :
mette d'une représentation donnée suggérerait qu'un ultérieurement obtenu sur cette même ressource cible entraînera une représentation équivalente envoyée dans un 200 (OK) réponse. [...]
POST , qui est un attraper tout verbe :
Je pense que la poste servirait mon but. Le rfc lien dit que le message peut être utilisé pour Fourniture d'un bloc des données, telles que les champs entrés dans un formulaire HTML, à un processus de traitement de données
@Ramakrishnashastri en effet. Il semble être la méthode la plus appropriée pour votre situation.
Donc, ma question est de savoir quelle est la méthode HTTP appropriée qui pourrait être utilisée dans ce scénario qui est acceptable dans le point de vue de la conception reposante.
Le Web World Wide Web est à peu près aussi content d'un exemple que vous allez trouver, et les formulaires HTML ne prend en charge que
obtenez (qui Ne doit pas avoir de corps de demande ) etPOST . Doncpost doit être bien (et c'est).plus généralement,
post peut être utilisé pour n'importe quoi; Les autres méthodes doivent être utilisées lorsqu'elles constituent un meilleur ajustement sémantique. Par exemple, vous pouvez utiliserpost pour créer une ressource indisponible, maisSupprimer est plus explicite et les composants génériques peuvent faire des choses sensibles parce qu'elles reconnaissent la sémantique.mettre est un meilleur choix quePOST lorsque vous souhaitez fournir au serveur une nouvelle représentation d'une ressource, etc.Je ne suis pas capable de comprendre pourquoi la charge utile du HTTP GET est interdite
La charge utile du HTTP Get est interdite car la norme indique "ne le fais pas".
Je crois que cela est écrit de cette façon de simplifier les règles de mise en cache de la réponse. Comme écrit, les implémentations de cache ne doivent être à soucier que des données d'en-tête (y compris des informations sur la ligne de départ).
Mais cela pourrait être aussi simple que le fait que les anciennes versions de la norme ne nécessitaient pas que des composants génériques ne font rien de spécifique avec le corps-corps d'une demande d'obtention, et donc les spécifications modernes disent "ne le faites pas "Afin de maintenir la compatibilité en arrière. (L'une des contraintes importantes dans la conception de systèmes de longue durée est que vous ne brisez pas les implémentations plus anciennes.)
Merci pour la réponse. Mais je ne suis pas en mesure de comprendre pourquoi la charge utile du HTTP GET est interdite avoir une sémantique de la demande et même si elle est interdite d'envoyer la représentation du côté serveur, en fonction de cette sémantique. Si vous pouviez éclairer cela, ce serait génial
Utilisez la méthode post-méthode pour la même chose.
Hey Ramakrishna! Vous avez récemment posé cette question et j'ai mis du temps et des efforts pour y répondre. Alors j'apprécie très bien tous les commentaires dans mon Répondre .
Salut Cassiomoline. Désolé d'ajouter un commentaire. J'apprécie vraiment votre réponse. Cela m'a aidé beaucoup. Merci