This project is read-only.

HTTP discoverability: OPTIONS method

Topics: Web Api
Nov 1, 2010 at 5:38 PM

The method OPTIONS could be automatically implemented based on the methods defined by the Resource, couldn't it? A URL could also be added with a human readable description of the resource (In the REST Starter kit this is accomplished by using the WebHelp attr I believe).

This may be more suitable for frameworks sitting on top the basic framework.. Thoughts?

I can think of different ways of implementing this:

- Base class

- Processor?

-Attribute at the class level

Nov 1, 2010 at 10:51 PM

This will be easier to do with the Resource model prototype that will show up a little later.  It's not as easy to do with the URITemplate / ServiceContract approach.  A base class probably would be easier to do, but it certainly would be possible to create a processor that manufactured a response for operations that were tagged with the Options method.

Nov 2, 2010 at 4:05 AM


You could do it with a processor, but you would have to have a dummy operation with a uri template. You could create this dummy operation through a custom service host. We are looking at expanding the HostConfiguration class so it can do much more than just processors. When we do, this type of stuff will be much easier as you won't need a custom service host.



Apr 17, 2011 at 7:23 PM

How would you guys implement this with the new bits? Do you think that a message channel is a good place to do that?

I was thinking of getting the resource type to be executed there and then use reflection to discover the operations implemented by the resource (webInvoke attr)

The resource type doesn't seem to be available in the message channel, the only way that I've found to get any closer to it is by looking at the routes.

 var routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(HttpContext.Current));
 var serviceRoute = routeData.Route as ServiceRoute;

Unfortunately ServiceRoute receives the resource type in the constructor but it doesn't expose it in a property. I could inherit from ServiceRoute to expose the property and create some routing extension methods to add them but... Am I missing sthing?

Apr 17, 2011 at 10:02 PM

If you are only planning to use Options to show which http methods are acceptable on the resource, then you probably could handle it in a channel. You will need to do a bit of work though as you mentioned. Channels run before operation selection thus we don't even know the type of the service which will get invoked at that point. As you said you will need to do a bit of work to get the type, but once you have it, you could look at the WebGet/WebInvoke attributes an piece together which methods are acceptable.

Now the sementics of Options are not defineed in stone, so you can actually add quite a bit more information like even which formats are accetable. That will be harder to do here as the formatters are scoped per operation.

For that situation then having a base class as Darrel said which has a [WebInvoke(Method="OPTIONS"]] on it which uses reflection to build up the list is probably the easiest way to do it.

Cheers Glenn