views:

425

answers:

2

This problem relates to the Restlet framework and Java

When a client wants to discover the resources available on a server - they must send an HTTP request with OPTIONS as the request type. This is fine I guess for non human readable clients - i.e. in code rather than a browser.

The problem I see here is - browsers (human readable) using GET, will NOT be able to quickly discover the resources available to them and find out some extra help documentation etc - because they do not use OPTIONS as a request type.

Is there a way to make a browser send an OPTIONS/GET request so the server can fire back formatted XML to the client (as this is what happens in Restlet - i.e. the server response is to send all information back as XML), and display this in the browser? Or have I got my thinking all wrong - i.e. the point of OPTIONS is that is meant to be used inside a client's code and not meant to be read via a browser.

+1  A: 

Use the TunnelService (which by default is already enabled) and simply add the method=OPTIONS query parameter to your URL.

(The Restlet FAQ Q19 is a similar question.)

Stephen Denne
Do you have any idea how you implement this - not much to go by just from the API docs. Cheers.
Vidar
It is enabled by default, created, and set up with default configuration in the Application(Context) constructor.
Stephen Denne
ok - I had some code that was meddling with TunnelService - so removed that and just from the browser - entered method=OPTIONS as you said and it works.
Vidar
+1  A: 

I think OPTIONS is not designed to be 'user-visible'.

How would you dispatch an OPTIONS request from the browser ? (note that the form element only allows GET and POST).

You could send it using XmlHttpRequest and then get back XML in your Javascript callback and render it appropriately. But I'm not convinced this is something that your user should really know about!

Brian Agnew