Oct 3rd, 2012, 05:12 AM
First class support for OPTIONS requests
In line with the general efforts to make REST a first class citizen in the Spring framework, I wanted to ask about the following usecase - support for OPTIONS HTTP requests. OPTIONS plays a large role in REST Discoverability (and helps with adhering to the HATEOAS constraint) - allowing a client of the API to gain more information about that particular URI - namely the `Allow` header specifying what HTTP Methods are allowed for that URI. There may be other information that can be retrieved by an OPTIONS request, but the `Allow` at least should be there by default.
Now, the current behavior of Spring is not to handle the OPTIONS requests by default (DispatcherServlet - dispatchOptionsRequest - false by default). however, even after that enabled, the OPTIONS request will default in a 405 Method Not Allowed (which, ironically, does correctly return the `Allow` header pointing to what methods are allowed). In order to actually get the correct 200 OK, one would have to explicitly map the URIs in the Controller (at which point I'm not sure the `Allow` header will even be part of the response).
This default behavior can be improved - by doing some or all of the following:
- enable the handling of OPTIONS requests by the DispatcherServlet
- respond with 200 OK and the `Allow` header for OPTIONS requests by default; this can of course be overridden (or possibly disabled) but the option should be there
This would bring the REST support up a notch and simply make more sense, as well as be alligned with what the HTTP spec define as standard behavior for responding to OPTIONS requests (http://tools.ietf.org/html/draft-iet...#section-2.3.1).
Should I open a JIRA issue to track this?
Oct 25th, 2012, 10:14 AM
Did you wind up opening a JIRA issue for this? If so, could you provide the link? I think this would be a great addition.
Oct 25th, 2012, 10:16 AM
Tags for this Thread