The OPTIONS Method
The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
This provides a way of binding a resource with it’s metadata in a way that doesn’t require any extensions to HTTP. I’ve seen one alternative method proposed, but it does involve the use of extension headers. If some standard convention ultimately emerges, I’ll move to that.
One concern that was raised was that RFC2616 states that the OPTIONS method is not cacheable; the concern being that it would be essentially impossible to know how long the OPTIONS response would be valid. Roy Fielding posted a clarification stating that this is just the default; cache-control can be employed, allowing the server to define how long the metadata is guaranteed to remain valid.
For any resource, the response to an OPTIONS request will return the list of available methods via the Allow header, as well as some as-yet-to-be-decided form of schema definition of what can be PUT or POSTed.