Dernière mise à jour: 1.11.2015
Contrairement aux requêtes GET, les données des requêtes POST ne sont pas transmises dans la ligne de la requête, mais dans son corps. Un exemple courant de telles requêtes consiste à envoyer des données de formulaire au serveur.
La méthode post est utilisée pour envoyer des requêtes POST. Sa déclaration et son utilisation sont généralement similaires à la méthode get. Il accepte les paramètres suivants :
url : un paramètre obligatoire contenant l'adresse de la ressource à laquelle la requête accédera
data : un paramètre facultatif contenant un simple objet ou une chaîne javascript qui sera envoyé au serveur avec la requête
success(data, textStatus, jqXHR) : paramètre facultatif - une fonction de rappel qui sera exécutée lorsque la requête aboutira. Il peut prendre trois paramètres : data - données reçues du serveur, textStatus - l'état de la demande et jqXHR - un objet jQuery spécial qui représente une version étendue de l'objet XMLHttpRequest.
dataType : un paramètre facultatif contenant le type de données sous forme de chaîne, tel que "xml" ou "json"
En sortie, la méthode post renvoie un objet jqXHR.
Exemple d'utilisation :
$.post("ajax.php", ("login": "1111", "mot de passe" : "2222"), function(data) ( $("#news").html(data); ));
Dans ce cas, nous transmettons le mot de passe et le login sous forme de données. Sur le serveur, nous pouvons recevoir des données et envoyer une réponse à l'utilisateur :
Étant donné que la demande de publication est le plus souvent utilisée lors de l'envoi de données de formulaire, nous utilisons le formulaire côté client :
$("#loginForm").submit(function(event) ( // Empêcher la soumission de formulaire régulière event.preventDefault(); $.post("ajax.php", ("login":$("#login"). val(), "mot de passe" : $("#password").val()), function(data) ( $("#result").html(data); )); ));
Ainsi, la partie serveur à laquelle le formulaire accédera – le fichier ajax.php – reste la même. Seulement dans ce cas, maintenant pour le paramètre data dans la méthode post, nous prenons les données des champs de ce formulaire.
Veuillez noter que nous bloquons la soumission normale du formulaire (event.preventDefault();), sinon nous aurions une redirection.
Sérialisation des formulairesÉtant donné que les formulaires ne sont souvent pas limités à deux champs, il est plus facile d’utiliser la sérialisation des formulaires. La sérialisation est effectuée à l'aide de la méthode serialize et crée par conséquent un objet javascript, où les propriétés correspondent aux champs du formulaire. Et les valeurs stockées par ces propriétés sont les mêmes que celles des champs de formulaire correspondants.
Alors, appliquons la sérialisation du formulaire :
$("#loginForm").submit(function(event) ( // Empêcher la soumission de formulaires réguliers event.preventDefault(); $.post("ajax.php", $("#loginForm").serialize(), function (données) ( $("#result").html(données); )); ));
Contrairement à l’exemple précédent, nous avons ici deux différences. Tout d’abord, notez que les champs de saisie ont un attribut de nom. Lors de la spécification du paramètre data, nous sérialisons les données du formulaire via la méthode serialize : $("#loginForm").serialize() . DANS cette méthode Les paramètres sont transmis au corps de la requête. De plus, les noms des paramètres sont les valeurs des attributs de nom des champs de saisie. Et les valeurs des paramètres sont les valeurs correspondantes saisies dans les champs de texte.
Et donc avec en utilisant php nous pouvons extraire ces valeurs : $login=$_POST["login"] .
Cet article est une réponse à une question posée dans l'un de mes articles.
Dans cet article, je veux vous expliquer ce que sont les méthodes HTTP GET/POST/PUT/DELETE et autres, pourquoi elles ont été inventées et comment les utiliser conformément à REST.
HTTP Alors, quel est l'un des principaux protocoles Internet ? J'enverrai les pédants vers RFC2616, et je raconterai le reste humainement :)Ce protocole décrit l'interaction entre deux ordinateurs (client et serveur), construite sur la base de messages appelés requête (Request) et réponse (Response). Chaque message se compose de trois parties : une ligne de départ, des en-têtes et un corps. Dans ce cas, seule la ligne de départ est requise.
Les lignes de départ de la demande et de la réponse sont format différent- nous ne nous intéressons qu'à la ligne de départ de la requête, qui ressemble à ceci :
URI DE LA MÉTHODE HTTP/ VERSION ,
Où METHOD est la méthode de requête HTTP, URI est l'identifiant de la ressource, VERSION est la version du protocole (pour ce moment la version 1.1 est actuelle).
Les en-têtes sont une collection de paires nom-valeur séparées par deux points. Les en-têtes véhiculent diverses informations sur le service : encodage du message, nom et version du navigateur, adresse d'où provient le client (Referrer), etc.
Le corps du message correspond aux données réelles transmises. Dans la réponse, les données transmises sont généralement la page HTML demandée par le navigateur, et dans la demande, par exemple, dans le corps du message, le contenu des fichiers téléchargés sur le serveur est transmis. Mais en règle générale, la demande ne contient aucun corps de message.
Exemple d'interaction HTTP Regardons un exemple.Demande:
GET /index.php HTTP/1.1 Hôte : example.com Agent utilisateur : Mozilla/5.0 (X11 ; U ; Linux i686 ; ru ; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accepter : text/html Connexion : fermer
La première ligne est la ligne de requête, les autres sont des en-têtes ; le corps du message est manquant
Répondre:
HTTP/1.0 200 OK Serveur : nginx/0.6.31 Langage du contenu : ru Type de contenu : text/html ; charset=utf-8 Content-Length : 1234 Connexion : fermer... LA PAGE HTML ELLE-MÊME...
Le type de requête HTTP (également appelé méthode HTTP) indique au serveur quelle action nous souhaitons effectuer sur la ressource. Initialement (au début des années 90), on supposait que le client ne pouvait vouloir qu'une seule chose d'une ressource : la recevoir, mais maintenant, en utilisant le protocole HTTP, vous pouvez créer des publications, modifier un profil, supprimer des messages et bien plus encore. Et ces actions sont difficiles à combiner avec le terme « reçu ».
Pour différencier les actions des ressources au niveau des méthodes HTTP, les options suivantes ont été inventées :
- GET - obtenir une ressource
- POST - création de ressources
- PUT - mise à jour des ressources
- DELETE - suppression de ressources
REST propose d'éviter d'utiliser le même URI pour différentes ressources (c'est-à-dire les adresses de deux divers articles comme /index.php?article_id=10 et /index.php?article_id=20 - ce n'est pas une méthode REST) et utilisez différentes méthodes HTTP pour différentes actions. C'est-à-dire qu'une application Web écrite à l'aide de l'approche REST supprimera une ressource lors de son accès avec la méthode HTTP DELETE (bien sûr, cela ne signifie pas qu'il est nécessaire de donner la possibilité de supprimer tout et tout le monde, mais n'importe lequel la demande de suppression de l'application doit utiliser la méthode HTTP DELETE).
REST donne aux programmeurs la possibilité d'écrire des applications Web standardisées et légèrement plus jolies qu'auparavant. En utilisant REST, l'URI pour ajouter un nouvel utilisateur ne sera pas /user.php?action=create (méthode GET/POST), mais simplement /user.php (méthode strictement POST).
En conséquence, en combinant la spécification HTTP existante et l’approche REST, diverses méthodes HTTP prennent enfin tout leur sens. GET - renvoie une ressource, POST - en crée une nouvelle, PUT - met à jour une ressource existante, DELETE - la supprime.
Problèmes? Oui, il y a un petit problème avec l'utilisation de REST dans la pratique. Ce problème s'appelle HTML.Les requêtes PUT/DELETE peuvent être envoyées à l'aide de XMLHttpRequest, en contactant le serveur manuellement (par exemple, via curl ou même via telnet), mais vous ne pouvez pas créer de formulaire HTML qui envoie une requête PUT/DELETE à part entière.
Le fait est que la spécification HTML ne vous permet pas de créer des formulaires qui soumettent des données autrement que via GET ou POST. Donc pour fonctionnement normal avec d’autres méthodes, il faut les imiter artificiellement. Par exemple, dans Rack (le mécanisme sur la base duquel Ruby interagit avec le serveur Web ; Rails, Merb et d'autres frameworks Ruby sont créés à l'aide de Rack), vous pouvez ajouter un champ caché au formulaire avec le nom "_method", et spécifiez le nom de la méthode comme valeur (par exemple "PUT") - dans ce cas, une requête POST sera envoyée, mais Rack pourra prétendre qu'il a reçu un PUT plutôt qu'un POST.
Cet article est une réponse à une question posée dans un commentaire sur l'un de mes articles.
Dans cet article, je veux vous expliquer ce que sont les méthodes HTTP GET/POST/PUT/DELETE et autres, pourquoi elles ont été inventées et comment les utiliser conformément à REST.
HTTP Alors, quel est l'un des principaux protocoles Internet ? J'enverrai les pédants vers RFC2616, et je raconterai le reste humainement :)Ce protocole décrit l'interaction entre deux ordinateurs (client et serveur), construite sur la base de messages appelés requête (Request) et réponse (Response). Chaque message se compose de trois parties : une ligne de départ, des en-têtes et un corps. Dans ce cas, seule la ligne de départ est requise.
Les lignes de départ de la demande et de la réponse ont des formats différents - nous nous intéressons uniquement à la ligne de départ de la demande, qui ressemble à ceci :
URI DE LA MÉTHODE HTTP/ VERSION ,
Où METHOD est la méthode de requête HTTP, URI est l'identifiant de la ressource, VERSION est la version du protocole (actuellement la version 1.1 est actuelle).
Les en-têtes sont une collection de paires nom-valeur séparées par deux points. Les en-têtes véhiculent diverses informations sur le service : encodage du message, nom et version du navigateur, adresse d'où provient le client (Referrer), etc.
Le corps du message correspond aux données réelles transmises. Dans la réponse, les données transmises sont généralement la page HTML demandée par le navigateur, et dans la demande, par exemple, dans le corps du message, le contenu des fichiers téléchargés sur le serveur est transmis. Mais en règle générale, la demande ne contient aucun corps de message.
Exemple d'interaction HTTP Regardons un exemple.Demande:
GET /index.php HTTP/1.1 Hôte : example.com Agent utilisateur : Mozilla/5.0 (X11 ; U ; Linux i686 ; ru ; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accepter : text/html Connexion : fermer
La première ligne est la ligne de requête, les autres sont des en-têtes ; le corps du message est manquant
Répondre:
HTTP/1.0 200 OK Serveur : nginx/0.6.31 Langage du contenu : ru Type de contenu : text/html ; charset=utf-8 Content-Length : 1234 Connexion : fermer... LA PAGE HTML ELLE-MÊME...
Le type de requête HTTP (également appelé méthode HTTP) indique au serveur quelle action nous souhaitons effectuer sur la ressource. Initialement (au début des années 90), on supposait que le client ne pouvait vouloir qu'une seule chose d'une ressource : la recevoir, mais maintenant, en utilisant le protocole HTTP, vous pouvez créer des publications, modifier un profil, supprimer des messages et bien plus encore. Et ces actions sont difficiles à combiner avec le terme « reçu ».
Pour différencier les actions des ressources au niveau des méthodes HTTP, les options suivantes ont été inventées :
- GET - obtenir une ressource
- POST - création de ressources
- PUT - mise à jour des ressources
- DELETE - suppression de ressources
REST suggère d'abandonner l'utilisation du même URI pour différentes ressources (c'est-à-dire les adresses de deux articles différents comme /index.php?article_id=10 et /index.php?article_id=20 - ce n'est pas une méthode REST) et en utilisant différentes méthodes HTTP pour différentes actions. C'est-à-dire qu'une application Web écrite à l'aide de l'approche REST supprimera une ressource lors de son accès avec la méthode HTTP DELETE (bien sûr, cela ne signifie pas qu'il est nécessaire de donner la possibilité de supprimer tout et tout le monde, mais n'importe lequel la demande de suppression de l'application doit utiliser la méthode HTTP DELETE).
REST donne aux programmeurs la possibilité d'écrire des applications Web standardisées et légèrement plus jolies qu'auparavant. En utilisant REST, l'URI pour ajouter un nouvel utilisateur ne sera pas /user.php?action=create (méthode GET/POST), mais simplement /user.php (méthode strictement POST).
En conséquence, en combinant la spécification HTTP existante et l’approche REST, diverses méthodes HTTP prennent enfin tout leur sens. GET - renvoie une ressource, POST - en crée une nouvelle, PUT - met à jour une ressource existante, DELETE - la supprime.
Problèmes? Oui, il y a un petit problème avec l'utilisation de REST dans la pratique. Ce problème s'appelle HTML.Les requêtes PUT/DELETE peuvent être envoyées à l'aide de XMLHttpRequest, en contactant le serveur manuellement (par exemple, via curl ou même via telnet), mais vous ne pouvez pas créer de formulaire HTML qui envoie une requête PUT/DELETE à part entière.
Le fait est que la spécification HTML ne vous permet pas de créer des formulaires qui soumettent des données autrement que via GET ou POST. Par conséquent, pour travailler normalement avec d’autres méthodes, il faut les imiter artificiellement. Par exemple, dans Rack (le mécanisme sur la base duquel Ruby interagit avec le serveur Web ; Rails, Merb et d'autres frameworks Ruby sont créés à l'aide de Rack), vous pouvez ajouter un champ caché au formulaire avec le nom "_method", et spécifiez le nom de la méthode comme valeur (par exemple "PUT") - dans ce cas, une requête POST sera envoyée, mais Rack pourra prétendre qu'il a reçu un PUT plutôt qu'un POST.
Création d'un standard de réseau Internet 2.0 a permis à l'utilisateur non seulement de recevoir des informations, mais également d'interagir activement avec d'autres utilisateurs et services Internet. Pour organiser ce feedback dans Langage HTML des balises supplémentaires ont été introduites pour permettre aux informations demandées d'être envoyées au serveur. Par exemple, il peut s'agir d'un formulaire d'inscription, d'un formulaire de commentaires ou d'un paramètre compte personnel(pages réseau social) et ainsi de suite. Dans ce chapitre, nous examinerons un ensemble de balises qui vous permettent d'organiser l'interaction des utilisateurs avec le site.
6.1. Requêtes GET et POSTPour organiser l'interaction des utilisateurs avec Internet, le développeur du site doit prévoir la transmission des requêtes de l'utilisateur du site vers le serveur sur lequel se trouve le site. Il existe deux types de requêtes : les requêtes GET et POST.
Requêtes GET
Au début du développement d’Internet, seules les requêtes GET existaient. Ils représentent le transfert de données directement vers la barre d'adresse du navigateur, ayant la syntaxe suivante :
http://domain/page?[parameter1=value1][¶meter2=value2]...
Ici, l'ensemble des données transférées vers le serveur commence par le caractère « ? » et est séparé par le caractère « & ». Les données elles-mêmes sont une paire
paramètre=valeur
Par exemple, si vous devez transmettre le nom et prénom de l'utilisateur sur la page d'inscription (par exemple, register.php) du site monsite.com, cela ressemblerait à ceci :
http://mysite.com/register.php?fname=Ivan&lname=Ivanov
Veuillez noter que les navigateurs de versions obsolètes peuvent ne pas percevoir correctement l'alphabet cyrillique et que la transmission des lettres russes s'effectuera de manière incorrecte. Il est préférable de transmettre exclusivement les informations de service dans les requêtes GET sous forme de chiffres et de mots en latin.
L'inconvénient des requêtes GET est le nombre limité de données transférées. Côté serveur, la chaîne de requête est limitée à une valeur maximale. Par exemple, si la taille maximale de la requête peut être de 1024 caractères, alors tout ce qui dépasse cette valeur sera supprimé et une partie des informations transmises ne sera pas traitée par la page spécifiée du site. La deuxième limitation importante est la capacité à transmettre des jeux de caractères strictement définis. Par exemple, des symboles ? et & sont déjà réservés et ne peuvent pas être transmis comme valeurs de paramètre. Cependant, cette règle peut être contournée si la chaîne de requête ne contient pas le caractère lui-même, mais sa valeur de code. Pour cela, utilisez le caractère '%' suivi du code du caractère, par exemple comme ceci :
http://mysite.com/register.php?fname=%CC%DF%AD%1F%DS&lname=%DD
Ici, les valeurs du code sont données en hexadécimal pour économiser la longueur de la requête.
Malgré ces inconvénients, créer des sites sans requêtes GET serait extrêmement difficile. Par exemple, ils sont indispensables en cas d'initialisation initiale d'une page du site pour un utilisateur précis, lorsque la demande précise non seulement le site et page actuelle, mais aussi son identifiant, comme cela se fait sur le réseau social VKontakte :
http://vk.com/profile.php?id=12345678
Les requêtes GET sont également souvent utilisées pour vérifier l'exactitude de l'adresse e-mail lors de l'enregistrement d'un utilisateur. Dans ce cas, l'utilisateur reçoit un e-mail avec un lien d'activation à l'adresse e-mail spécifiée, et ce lien est une requête GET.
Requêtes POST
Pour résoudre ces défauts des requêtes GET, des requêtes POST ont été ajoutées, permettant de transférer de grandes quantités de données sous forme binaire, c'est-à-dire sans distorsion ni modification des données transmises. De telles requêtes sont bien adaptées au téléchargement de fichiers et d'images sur le serveur. Par exemple, lorsqu'un utilisateur télécharge une image sur son profil de réseau social, des requêtes POST sont utilisées à cet effet. Plus de détails sur l'organisation des requêtes POST seront discutés ci-dessous.
Ce qu’ils ont en commun, c’est qu’ils fonctionnent de la même manière. Il n'y a techniquement aucune différence entre eux. Mais il existe des différences idéologiques.
J'en parlerai dans le contexte de PHP. Veuillez noter que Protocole HTTP a une relation indirecte avec PHP car il a été créé pour l'échange pages HTML et PHP étend simplement les capacités des deux.
La requête GET est utilisée pour recevoir des données et POST est utilisée pour envoyer. (N'oubliez pas que techniquement, ils fonctionnent de la même manière).
Par conséquent, dans le contexte de PHP, sur la base de cette idéologie, nous avons fait ce qui suit :
1. Chaque fois que vous démarrez PHP, des tableaux superglobaux ($_GET, $_POST) sont créés par défaut.
2. S'il y a un point d'interrogation (?) dans la chaîne de requête. Tout ce qui suit est considéré comme des paramètres Requête OBTENIR ils sont présentés au format "key"="value" et sont séparés par le caractère esperluette (&)
Exemple:
GET /index.php?name=Andrey&surname=Galkin
Il s'agit d'une chaîne de requête, il y a 2 paramètres. ces paramètres iront dans le tableau $_GET.
3. $_POST est rempli d'une manière différente. le contenu de ce tableau est rempli à partir des "en-têtes de requête". C’est-à-dire depuis un endroit clairement caché. Le navigateur s'occupe de toutes les tâches de création de ces en-têtes. Bien que parfois quelque chose soit modifié manuellement dans les titres.
Le plus souvent, une demande de publication est utilisée dans des formulaires (pour envoyer des données).
Par exemple, nous avons un formulaire de connexion avec 2 champs : login et mot de passe.
Imaginons ce que nous utilisons Méthode OBTENIR. Ensuite, lors de la soumission du formulaire, nous nous rendrons à l'adresse suivante /login.php?login=Andrey&password=123 Vous conviendrez que transmettre de telles informations de cette manière n'est pas du tout sûr. N'importe qui peut ouvrir votre navigateur et, en commençant à saisir l'adresse du site, il peut voir vos mots de passe et vos identifiants à partir de l'historique.
Mais si on indiquait Méthode POST alors nous recevrions la demande suivante :
POST /login.php (login=Andrey&password=123) ce qui est entre parenthèses serait masqué et ne serait en aucun cas enregistré dans le navigateur.
Résumer:
GET est d'obtenir page spécifique sous une certaine forme (tri, page de blog actuelle, barre de recherche, etc.).
POST - pour l'envoi de données qui n'affectent pas l'affichage de la page, dans le sens où ces données n'affectent que le résultat du script (identifiants, mots de passe, numéros de carte de crédit, messages, etc.).
Et une autre bonne nouvelle, c'est qu'ils peuvent être combinés, par exemple
POST /index.php?page=login (login=Andrey&password=123) Je pense avoir déjà suffisamment expliqué ce qui en résultera et quels paramètres entreront dans quel tableau.