views:

1296

answers:

4

Can I do the following?

[OperationContract]
[WebGet(UriTemplate = "/foo/{id}")]
string GetFoo(int id);

I'd like my service to function as both RESTful service and RPC-style SOAP service. If possible I'd like to retain int as int, and not do parsing by hand.

+2  A: 

Unfortunately you must do the parsing yourself if you want to use the UriTemplate.

Andrew Hare
A: 

If I understand your question correctly, then I think it is possible.

When the operation contract is exposed as a REST endpoint, then a GET request on "foo/123" will yield the desired result since the URI template automatically maps it to an int and the implementation of GetFoo can use id as an int.

When the same operation contract is exposed as a SOAP endpoint, the proxy(created via a ChannelFactory or derived from ClientBase ) will expose it as int.

I hope that answers your question.

Prashanth
I get error message "Operation 'GetFoo' in contract 'IFooService' has a path variable named 'id' which does not have type 'string'. Variables for UriTemplate path segments must have type 'string'." Can you show me the code that works?
eed3si9n
+4  A: 

If I remember correctly, UriTemplate variables in the path always resolve to strings when using WebGet or WebInvoke. You can only bind UriTemplate variables to int, long, etc. when they are in the query portion of the UriTemplate.

dthrasher
+4  A: 

As dthrasher mentioned, move id to the query part of the URI. This worked for me:

[OperationContract]
[WebGet(UriTemplate = "/foo?id={id}")]
string GetFoo(int id);

See "URI scheme" on wikipedia for more info about the different parts of a URI: http://en.wikipedia.org/wiki/URI_scheme

Cameron Taggart