This project is read-only.

AddServiceRoute and multi-element UriTemplates

Topics: Web Api
Jan 18, 2011 at 8:08 PM

I've been looking over the project the last couple of days, to see if I can prototype a REST interface that could sit alongside our traditional SOAP exposed interface.

So far, I have mainly focussed on seeing how our hierarchical 'explorer tree' data structure might be represented - which has gone pretty well, far better than the WCF Data Services prototype went.

However, I've hit a bit of a bump when trying to understand how we should use ServiceRoutes and in particular get multi-element UriTemplates to go through to the Resource class.

My reason for doing this is that our system can look up a resource item via slightly more expensive calls to locate something merely knowing a GUID. However, if you know the type of resource you want we can look this item up more efficently at the back-end.

I can grab two pieces of data from a WebGet (using a template of {type}/{id} which is great, but this only works if I add a ServiceRoute that directs the whole root path to one Resource. Now, this is OK as long as I never want to extend this root path to handle types through a new dedicated class.

I could get around this by mapping out the 'type' element by adding many ServiceRoutes, so I can always extend by adding a new Resource class targetted from a different configuration. However, I can't see a way to tell from inside the Resource class which route was used to arrive at the WebGet.

If it was possible to tell what ServiceRoute was used, I could reuse the same resource classes for similar types and extend to specialised ones when I need. But I can't...

So my choices are hope I can always update some 'master' resource class and handling the first level of redirecting inside that, or to create many ServiceRoutes with a one-to-one set of configurations / resource classes to service them.

Am I missing something? Is this something you might want to add to a future extension to the routing behaviours?




Jan 19, 2011 at 6:12 PM

Right, i was missing a crucial bit of knowledge - you can add an entry to the method signature anything decorated with WebGets to allow the request as well as the response to be available inside the method.

This would mean if you do this...

        [WebGet(UriTemplate = "{id}")]
        public Item Get(string id, HttpResponseMessage response, HttpRequestMessage request)
            //do something useful

You can now see what the URL that was requested was, and check headers.It seems that the samples I was looking at only included a variable to allow accessto the response object (and my powers of understanding exactly what magic you can sprinkle inside the method and get results from are weak).

Thanks Glenn for your help on Twitter.