Verbose, mais copié à partir de la spécification de la méthode HTTP 1.1 à http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
9.3 OBTENIR
La méthode GET signifie récupérer toutes les informations (sous la forme d'une entité) identifiées par l'URI de demande. Si l'URI de demande fait référence à un processus de production de données, ce sont les données produites qui doivent être renvoyées en tant qu'entité dans la réponse et non le texte source du processus, sauf si ce texte se trouve être la sortie du processus.
La sémantique de la méthode GET devient un "GET conditionnel" si le message de demande comprend un champ d'en-tête If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match ou If-Range. Une méthode GET conditionnelle demande que l'entité soit transférée uniquement dans les circonstances décrites par le ou les champs d'en-tête conditionnels. La méthode GET conditionnelle est destinée à réduire l'utilisation inutile du réseau en permettant aux entités mises en cache d'être actualisées sans nécessiter plusieurs demandes ou transférer des données déjà détenues par le client.
La sémantique de la méthode GET passe à un "GET partiel" si le message de demande comprend un champ d'en-tête Range. Un GET partiel demande que seule une partie de l'entité soit transférée, comme décrit dans la section 14.35. La méthode GET partielle est destinée à réduire l'utilisation inutile du réseau en permettant aux entités partiellement récupérées de se terminer sans transférer les données déjà détenues par le client.
La réponse à une demande GET peut être mise en cache si et seulement si elle répond aux exigences de mise en cache HTTP décrites dans la section 13.
Voir la section 15.1.3 pour les considérations de sécurité lors de l'utilisation pour les formulaires.
9.5 POST
La méthode POST est utilisée pour demander au serveur d'origine d'accepter l'entité incluse dans la demande en tant que nouveau subordonné de la ressource identifiée par l'URI de demande dans la ligne de demande. POST est conçu pour permettre à une méthode uniforme de couvrir les fonctions suivantes:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
La fonction réelle exécutée par la méthode POST est déterminée par le serveur et dépend généralement de l'URI de demande. L'entité publiée est subordonnée à cet URI de la même manière qu'un fichier est subordonné à un répertoire qui le contient, un article de presse est subordonné à un groupe de discussion auquel il est publié ou un enregistrement est subordonné à une base de données.
L'action effectuée par la méthode POST peut ne pas aboutir à une ressource qui peut être identifiée par un URI. Dans ce cas, 200 (OK) ou 204 (Pas de contenu) est le statut de réponse approprié, selon que la réponse inclut ou non une entité qui décrit le résultat.
Si une ressource a été créée sur le serveur d'origine, la réponse DEVRAIT être 201 (créée) et contenir une entité qui décrit le statut de la demande et fait référence à la nouvelle ressource, et un en-tête Location (voir section 14.30).
Les réponses à cette méthode ne peuvent pas être mises en cache, sauf si la réponse inclut des champs d'en-tête Cache-Control ou Expires appropriés. Cependant, la réponse 303 (Voir Autre) peut être utilisée pour demander à l'agent utilisateur de récupérer une ressource pouvant être mise en cache.
Les demandes POST DOIVENT respecter les exigences de transmission des messages énoncées au paragraphe 8.2.
Voir la section 15.1.3 pour des considérations de sécurité.
9.6 PUT
La méthode PUT demande que l'entité incluse soit stockée sous l'URI de demande fourni. Si l'URI de demande fait référence à une ressource déjà existante, l'entité incluse DEVRAIT être considérée comme une version modifiée de celle résidant sur le serveur d'origine. Si l'URI de demande ne pointe pas vers une ressource existante et que cet URI peut être défini comme nouvelle ressource par l'agent utilisateur demandeur, le serveur d'origine peut créer la ressource avec cet URI. Si une nouvelle ressource est créée, le serveur d'origine DOIT en informer l'agent utilisateur via la réponse 201 (créée). Si une ressource existante est modifiée, les codes de réponse 200 (OK) ou 204 (sans contenu) DEVRAIENT être envoyés pour indiquer la réussite de la demande. Si la ressource n'a pas pu être créée ou modifiée avec l'URI de demande, Une réponse d'erreur DEVRAIT être donnée qui reflète la nature du problème. Le destinataire de l'entité NE DOIT PAS ignorer les en-têtes Content- * (par exemple Content-Range) qu'il ne comprend pas ou n'implémente pas et DOIT retourner une réponse 501 (non implémentée) dans de tels cas.
Si la demande passe par un cache et que l'URI de demande identifie une ou plusieurs entités actuellement mises en cache, ces entrées DEVRAIENT être traitées comme périmées. Les réponses à cette méthode ne peuvent pas être mises en cache.
La différence fondamentale entre les requêtes POST et PUT se reflète dans la signification différente de l'URI de demande. L'URI dans une demande POST identifie la ressource qui gérera l'entité incluse. Cette ressource peut être un processus d'acceptation de données, une passerelle vers un autre protocole ou une entité distincte qui accepte les annotations. En revanche, l'URI dans une demande PUT identifie l'entité jointe à la demande - l'agent utilisateur sait quel URI est prévu et le serveur NE DOIT PAS tenter d'appliquer la demande à une autre ressource. Si le serveur souhaite que la demande soit appliquée à un URI différent,
il DOIT envoyer une réponse 301 (déplacée en permanence); l'agent utilisateur PEUT alors prendre sa propre décision concernant la redirection ou non de la demande.
Une seule ressource PEUT être identifiée par de nombreux URI différents. Par exemple, un article peut avoir un URI pour identifier "la version actuelle" qui est distincte de l'URI identifiant chaque version particulière. Dans ce cas, une demande PUT sur un URI général peut entraîner la définition de plusieurs autres URI par le serveur d'origine.
HTTP / 1.1 ne définit pas comment une méthode PUT affecte l'état d'un serveur d'origine.
Les demandes PUT DOIVENT respecter les exigences de transmission des messages énoncées au paragraphe 8.2.
Sauf indication contraire pour un en-tête d'entité particulier, les en-têtes d'entité dans la demande PUT DEVRAIENT être appliqués à la ressource créée ou modifiée par le PUT.
9.7 SUPPRIMER
La méthode DELETE demande au serveur d'origine de supprimer la ressource identifiée par l'URI de demande. Cette méthode PEUT être remplacée par une intervention humaine (ou tout autre moyen) sur le serveur d'origine. Le client ne peut pas garantir que l'opération a été effectuée, même si le code d'état renvoyé par le serveur d'origine indique que l'action s'est terminée avec succès. Cependant, le serveur NE DEVRAIT PAS indiquer de succès sauf si, au moment où la réponse est donnée, il a l'intention de supprimer la ressource ou de la déplacer vers un emplacement inaccessible.
Une réponse réussie DEVRAIT être 200 (OK) si la réponse comprend une entité décrivant l'état, 202 (Accepté) si l'action n'a pas encore été exécutée, ou 204 (Pas de contenu) si l'action a été exécutée mais la réponse ne comprend pas une entité.
Si la demande passe par un cache et que l'URI de demande identifie une ou plusieurs entités actuellement mises en cache, ces entrées DEVRAIENT être traitées comme périmées. Les réponses à cette méthode ne peuvent pas être mises en cache.