Is it possible to have "overloaded" uritemplates?
Asked Answered
D

3

8
        [OperationContract]
    [WebGet(UriTemplate = "/searchresults/{searchTerm}/{searchType}", ResponseFormat = WebMessageFormat.Xml, RequestFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare)]
    Message GetSearchResults(string searchTerm, string searchType);

    [OperationContract]
    [WebGet(UriTemplate = "/searchresults/{searchTerm}", ResponseFormat = WebMessageFormat.Xml, RequestFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare)]
    Message GetSearchResults(string searchTerm);

Is this possible - if not, can someone suggest an alternative?

Doss answered 9/9, 2010 at 11:18 Comment(0)
D
10

I've found that this was the best solution for me:

    [OperationContract(Name = "SearchresultsWithSearchType")]
    [WebGet(UriTemplate = "/searchresults/{searchTerm}/{searchType=null}", 
    ResponseFormat = WebMessageFormat.Xml)]
    Message GetSearchResults(string searchTerm, string searchType);


    [OperationContract(Name = "SearchresultsWithoutSearchType")]
    [WebGet(UriTemplate = "/searchresults/{searchTerm}", 
    ResponseFormat = WebMessageFormat.Xml)]
    Message GetSearchResults(string searchTerm);

this matches:

"http://myservice/searchresults/mysearchterm"

"http://myservice/searchresults/mysearchterm/"

"http://myservice/searchresults/mysearchterm/mysearchtype"

Doss answered 9/9, 2010 at 12:58 Comment(2)
Does this really work for you? WCF doesn't usually allow two operations with the same name.Platelayer
it did work for me - the Name property of the OperationContract attribute differentiates the two. However, the underlying methods still need different signatures.Oligarchy
Y
1

No, not really - because the string parameter searchType can be NULL - so you don't really have any way to distinguish the two URL templates. It would be different if you were using a non-nullable type, like an INT or something - then you (and the .NET runtime) could keep the two URL templates apart (based on the fact whether or not the INT is present).

What you need to do is just check whether searchType is empty or NULL in your GetSearchResults method, and act accordingly.

[OperationContract]
[WebGet(UriTemplate = "/searchresults/{searchTerm}/{searchType}", ResponseFormat = WebMessageFormat.Xml, RequestFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare)]
Message GetSearchResults(string searchTerm, string searchType);

and in your implementation:

public Message GetSearchResults(string searchTerm, string searchType)
{
   if(!string.IsNullOrEmpty(searchType))
   {
      // search with searchType
   }
   else
   {
      // search without searchType
   }
   ......
}
Yttrium answered 9/9, 2010 at 11:22 Comment(2)
Thanks - my problem is: "myservice/searchresults/searchterm" or "myservice/searchresults/searchterm" i.e. without the searchType part of the URL will not match the template above and returns a 404. Do i need to default the searchType parameter?Doss
@pones: ok - hmm.... I was under the impression it would match that template. But seems you do need the two URI templates after all. Thanks for sharing your insights!Yttrium
J
0

I achieved this by using STREAM to pass data from client. You can even have 2 operations with same name but different method name. from front end make sure to set contentType as "text/javascript" OR "application/octet-stream", and try sending data as POST from HTML or in data variabke if using AJAX or jQuery

For Example

[OperationContract]
[WebInvoke(Method = "PUT", UriTemplate = "user/id/{id}/", ResponseFormat = WebMessageFormat.Json, RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped)]
        string UpdateUser(string id, System.IO.Stream stream);

[OperationContract]
[WebInvoke(Method = "DELETE", UriTemplate = "user/id/{id}/", ResponseFormat = WebMessageFormat.Json, RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped)]
        string DeleteUser(string id);

OR substitute PUT and DELETE for GET and POST

Jobber answered 16/6, 2014 at 12:14 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.