This quote is the crux, of why I want to get some discussion around this thread’s topic.
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.
If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.
The response body, if any, SHOULD also include information about the communication options
The problem we are trying to solve, is getting our available “communication options”, from the server. This is exactly what the
OPTIONS method tries to solve.
OPTIONS requests may include a body, and we can use this body to get exactly the type of “options” we care about a particular point in time. The
OPTIONS body would include, all allowed methods, the attributes and relationships for the resource, and all query parameters.
In my opinion such a response should include validation information, for each of the attributes, such that the client can reasonably validate the content it is sending to the server, without making a round trip. This would be validations for length and for example format.