Méthodes API RESTful; HEAD & OPTIONS
J'écris un module d'API RESTful pour une application en PHP, et je suis un peu mélangé sur les verbes HEAD et OPTIONS.
OPTIONSUtilisé pour récupérer les verbes HTTP disponibles pour une ressource donnée?HEADUtilisé pour déterminer si une ressource donnée est disponible?
Si quelqu'un pouvait clarifier * ces verbes, ce serait très apprécié.
* La clarification concerne les architectures d'API RESTful reformulant les verbes HTTP. Depuis, je me suis rendu compte que HEAD et OPTIONS devraient pas être réutilisés et se comporter de manière prévisible comme toute application HTTP le devrait. Oh, comment nous grandissons en 2 ans.
Selon: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
9.2 OPTIONS
La méthode OPTIONS représente une demande d'informations sur les options de communication disponibles sur la chaîne de demande/réponse identifiée par l'URI de demande. Cette méthode permet au client de déterminer les options et/ou les exigences associées à une ressource, ou les fonctionnalités d'un serveur, sans impliquer d'action de ressource ni de lancement d'une récupération de ressource.
Les réponses à cette méthode ne peuvent pas être mises en cache.
Si la demande OPTIONS inclut un corps d'entité (comme indiqué par la présence de Content-Length ou Transfer-Encoding), le type de support DOIT alors être indiqué par un champ Content-Type. Bien que cette spécification ne définisse aucune utilisation d'un tel corps, les futures extensions HTTP pourraient utiliser le corps OPTIONS pour effectuer des requêtes plus détaillées sur le serveur. Un serveur qui ne prend pas en charge une telle extension PEUT supprimer le corps de la demande.
Si l'URI de demande est un astérisque ("*"), la demande OPTIONS est destinée à s'appliquer au serveur en général plutôt qu'à une ressource spécifique. Etant donné que les options de communication d'un serveur dépendent généralement de la ressource, la requête "*" n'est utile qu'en tant que méthode de type "ping" ou "sans opération"; il ne fait rien au-delà de permettre au client de tester les capacités du serveur. Par exemple, cela peut être utilisé pour tester un proxy pour la conformité HTTP/1.1 (ou son absence).
Si l'URI de la demande n'est pas un astérisque, la demande OPTIONS s'applique uniquement aux options disponibles lors de la communication avec cette ressource.
Une réponse 200 DEVRAIT inclure tous les champs d'en-tête qui indiquent les fonctionnalités facultatives implémentées par le serveur et applicables à cette ressource (par exemple, Autoriser), y compris éventuellement des extensions non définies par cette spécification. Le corps de la réponse, le cas échéant, DEVRAIT également inclure des informations sur les options de communication. Le format d'un tel corps n'est pas défini par cette spécification, mais pourrait être défini par de futures extensions à HTTP. La négociation de contenu PEUT être utilisée pour sélectionner le format de réponse approprié. Si aucun corps de réponse n'est inclus, la réponse DOIT inclure un champ Content-Length avec une valeur de champ de "0".
Le champ d'en-tête de demande Max-Forwards PEUT être utilisé pour cibler un proxy spécifique dans la chaîne de demandes. Lorsqu'un mandataire reçoit une demande OPTIONS sur une absolueURI pour laquelle le transfert de demande est autorisé, le mandataire DOIT vérifier la présence d'un champ Max-Forwards. Si la valeur du champ Max-Forwards est zéro ("0"), le mandataire NE DOIT PAS transmettre le message; au lieu de cela, le mandataire DEVRAIT répondre avec ses propres options de communication. Si la valeur du champ Max-Forwards est un entier supérieur à zéro, le mandataire DOIT décrémenter la valeur du champ lorsqu'il transmet la demande. Si aucun champ Max-Forwards n'est présent dans la demande, la demande transférée NE DOIT PAS inclure de champ Max-Forwards.
9.4 HEAD
La méthode HEAD est identique à GET, sauf que le serveur NE DOIT PAS renvoyer de corps de message dans la réponse. La métainformation contenue dans les en-têtes HTTP en réponse à une demande HEAD DEVRAIT être identique à l'information envoyée en réponse à une demande GET. Cette méthode peut être utilisée pour obtenir des métainformations sur l'entité impliquée par la demande sans transférer le corps d'entité lui-même. Cette méthode est souvent utilisée pour tester la validité, l’accessibilité et les modifications récentes des liens hypertextes.
La réponse à une demande HEAD PEUT être mise en cache en ce sens que les informations contenues dans la réponse PEUVENT être utilisées pour mettre à jour une entité précédemment mise en cache à partir de cette ressource. Si les nouvelles valeurs de champ indiquent que l'entité mise en cache diffère de l'entité actuelle (comme l'indique une modification de Content-Length, Content-MD5, ETag ou Last-Modified), le cache DOIT alors traiter l'entrée de cache comme étant périmée.
OPTIONS la méthode renvoie des informations sur [~ # ~] api [~ # ~] (méthodes/type de contenu)
La méthode HEAD renvoie des informations sur la ressource (version/longueur/type)
Réponse du serveur
[~ # ~] options [~ # ~]
HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0
[~ # ~] tête [~ # ~]
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270
OPTIONSIdentification des méthodes HTTP prises en charge par une ressource, par exemple. Pouvons-nous le supprimer ou le mettre à jour via un PUT?HEADVérifier si une ressource a été modifiée. Ceci est utile lors de la maintenance d'une version en cache d'une ressourceHEADRécupération de métadonnées sur la ressource, par exemple. son type de support ou sa taille, avant de procéder à une récupération éventuellement coûteuseHEAD, OPTIONSTeste si une ressource existe et est accessible. Par exemple, valider les liens soumis par l'utilisateur dans une application
Here est un article agréable et concis sur la manière dont HEAD et les options sont compatibles avec l'architecture RESTful.
OPTIONS vous dit des choses telles que "Quelles méthodes sont autorisées pour cette ressource".
HEAD obtient l'en-tête HTTP que vous obtiendriez si vous faisiez une requête GET, mais sans le corps. Cela permet au client de déterminer les informations de mise en cache, quel type de contenu serait renvoyé, quel code d'état serait renvoyé. La disponibilité n'en est qu'une petite partie.