Why does the WCF 3.5 REST Starter Kit do this?

Question

I am setting up a REST endpoint that looks like the following:

[WebInvoke(Method = "POST", UriTemplate = "?format=json", BodyStyle = WebMessageBodyStyle.WrappedRequest, ResponseFormat = WebMessageFormat.Json)]

and

[WebInvoke(Method = "DELETE", UriTemplate = "?token={token}&format=json", ResponseFormat = WebMessageFormat.Json)]

The above throws the following error:

UriTemplateTable does not support '?format=json' and '?token={token}&format=json' since they are not equivalent, but cannot be disambiguated because they have equivalent paths and the same common literal values for the query string. See the documentation for UriTemplateTable for more detail.

I am not an expert at WCF, but I would imagine that it should map first by the HTTP Method and then by the URI Template. It appears to be backwards. If both of my URI templates are:

?token={token}&format=json

This works because they are equivalent and it then appears to look at the HTTP Method where one is POST and the other is DELETE.

Is REST supposed to work this way? Why are the URI Template Tables not being sorted first by HTTP Method and then by URI Template? This can cause some serious frustrations when 1 HTTP Method requires a parameter and another does not, or if I want to do optional parameters (e.g. if the 'format' parameter is not passed, default to XML).

Answer 1

I believe this is simply a limitation of the routing capability of the UriTemplateTable. This is not a REST issue, just a WCF one I'm afraid.

Have you tried replicating the error in .Net 4.0? They seem to have done quite a bit of work to further support REST scenarios in .Net 4.

Answer 2

To fix this I had to do the following with my POST method:

[WebInvoke(Method = "POST", UriTemplate = "?token={token}&format=json", BodyStyle = WebMessageBodyStyle.WrappedRequest, ResponseFormat = WebMessageFormat.Json)]

My method declaration then took in an additional parameter called 'string token'. I then just ignore the value of 'token' in my method. If the client does not pass a value for token, WCF passes a null string, but since I am not working with it, it did not matter.

This is still frustrating with WCF 3.5, but it is a good workaround if anyone else runs into this.