Métodos API RESTful; CABEZAL Y OPCIONES

Estoy escribiendo un módulo de API RESTful para una aplicación en PHP, y estoy un poco mezclado con los verbos HEADy OPTIONS.

• OPTIONS  ¿Se utiliza para recuperar los verbos HTTP disponibles para un recurso determinado?
• HEAD ¿Se utiliza para determinar si un recurso determinado está disponible?

Si alguien pudiera aclarar * estos verbos, sería muy apreciado.

_{* La aclaración fue con respecto a las arquitecturas de API RESTful que reutilizan los verbos HTTP. Desde entonces, me he dado cuenta de que ambos HEADy noOPTIONS deben tener un nuevo propósito, y en su lugar deben comportarse de manera predecible como lo haría cualquier aplicación HTTP. Oh, cómo crecemos en 2 años.}

Según: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2 OPCIONES

El método OPTIONS representa una solicitud de información sobre las opciones de comunicación disponibles en la cadena de solicitud / respuesta identificada por el Request-URI. Este método permite al cliente determinar las opciones y / o requisitos asociados con un recurso, o las capacidades de un servidor, sin implicar una acción de recurso o iniciar una recuperación de recurso.

Las respuestas a este método no se pueden almacenar en caché.

Si la petición OPTIONS incluye un cuerpo de entidad (como lo indica la presencia de Content-Length o Transfer-Encoding), el tipo de medio DEBE indicarse mediante un campo Content-Type. Aunque esta especificación no define ningún uso para dicho cuerpo, las futuras extensiones de HTTP podrían usar el cuerpo OPTIONS para realizar consultas más detalladas en el servidor. Un servidor que no admita dicha extensión PUEDE descartar el cuerpo de la solicitud.

Si el Request-URI es un asterisco ("*"), la solicitud OPTIONS está destinada a aplicarse al servidor en general en lugar de a un recurso específico. Dado que las opciones de comunicación de un servidor generalmente dependen del recurso, la solicitud "*" solo es útil como método de tipo "ping" o "no-op"; no hace nada más que permitir que el cliente pruebe las capacidades del servidor. Por ejemplo, esto se puede usar para probar un proxy para el cumplimiento de HTTP / 1.1 (o la falta de él).

Si el Request-URI no es un asterisco, la solicitud OPTIONS se aplica solo a las opciones que están disponibles al comunicarse con ese recurso.

Una respuesta 200 DEBE incluir cualquier campo de encabezado que indique características opcionales implementadas por el servidor y aplicables a ese recurso (por ejemplo, Permitir), posiblemente incluyendo extensiones no definidas por esta especificación. El cuerpo de respuesta, si lo hubiera, DEBERÍA también incluir información sobre las opciones de comunicación. El formato de dicho cuerpo no está definido por esta especificación, pero podría estar definido por futuras extensiones de HTTP. La negociación de contenido PUEDE usarse para seleccionar el formato de respuesta apropiado. Si no se incluye un cuerpo de respuesta, la respuesta DEBE incluir un campo Content-Length con un valor de campo de "0".

El campo de encabezado de solicitud Max-Forwards PUEDE usarse para apuntar a un proxy específico en la cadena de solicitud. Cuando un proxy recibe una solicitud OPTIONS en una URL absoluta para la que se permite el reenvío de solicitudes, el proxy DEBE verificar un campo Max-Forwards. Si el valor del campo Max-Forwards es cero ("0"), el proxy NO DEBE reenviar el mensaje; en cambio, el proxy DEBE responder con sus propias opciones de comunicación. Si el valor del campo Max-Forwards es un número entero mayor que cero, el proxy DEBE disminuir el valor del campo cuando reenvía la solicitud. Si no hay ningún campo Max-Forwards presente en la solicitud, entonces la solicitud reenviada NO DEBE incluir un campo Max-Forwards.

9.4 CABEZA

El método HEAD es idéntico a GET, excepto que el servidor NO DEBE devolver un cuerpo de mensaje en la respuesta. La metainformación contenida en los encabezados HTTP en respuesta a una solicitud HEAD DEBERÍA ser idéntica a la información enviada en respuesta a una solicitud GET. Este método se puede utilizar para obtener metainformación sobre la entidad implícita en la solicitud sin transferir la entidad-cuerpo en sí. Este método se utiliza a menudo para probar enlaces de hipertexto para verificar su validez, accesibilidad y modificaciones recientes.

La respuesta a una solicitud HEAD PUEDE almacenarse en caché en el sentido de que la información contenida en la respuesta PUEDE usarse para actualizar una entidad previamente almacenada en caché desde ese recurso. Si los nuevos valores de campo indican que la entidad almacenada en caché difiere de la entidad actual (como lo indicaría un cambio en Content-Length, Content-MD5, ETag o Last-Modified), entonces la caché DEBE tratar la entrada de la caché como obsoleta.

OPTIONSel método devuelve información sobre la API (métodos / tipo de contenido)

HEADel método devuelve información sobre el recurso (versión / longitud / tipo)

Respuesta del servidor

OPCIONES

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

CABEZA

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

• OPTIONS Identificar qué métodos HTTP admite un recurso, por ejemplo, ¿podemos BORRARlo o actualizarlo mediante un PUT?
• HEADComprobando si un recurso ha cambiado. Esto es útil cuando se mantiene una versión en caché de un recurso.
• HEAD Recuperar metadatos sobre el recurso, por ejemplo, su tipo de medio o su tamaño, antes de realizar una recuperación posiblemente costosa
• HEAD, OPTIONSProbar si un recurso existe y es accesible. Por ejemplo, validar los enlaces enviados por el usuario en una aplicación

Aquí hay un artículo agradable y conciso sobre cómo HEAD y OPTIONS encajan en la arquitectura RESTful.

OPCIONES le dice cosas como "Qué métodos están permitidos para este recurso".

HEAD obtiene el encabezado HTTP que obtendría si realizara una solicitud GET, pero sin el cuerpo. Esto permite al cliente determinar la información de almacenamiento en caché, qué tipo de contenido se devolverá, qué código de estado se devolverá. La disponibilidad es solo una pequeña parte.