tags:

views:

73

answers:

1

Can someone explain the reason behind this or how it works? IF I do a WebInvoke on the following, it fails (says method not allowed, but if I do a WebGet, it passes). I just want to understand why?

[OperationContract]
[WebGet(UriTemplate = "login/{username}/{password}", ResponseFormat =  
                                                        WebMessageFormat.Json)]
string Login(string username, string password);

The above code, just returns a hard coded string. (No conditional logic)

+3  A: 

EDIT: Rewritten somewhat now I've reread the question...

WebInvoke allows you to specify which verb will be allowed, defaulting to POST. WebGet requires the client to be using a GET request. In either case, if the wrong verb is used, you'll get "method is not allowed". You were using the browser, so it was making a GET request, so a normal POST-only WebInvoke would reject it, whereas a WebGet would allow it. You could specify Method="GET" in the WebInvoke attribute declaration to allow GET, of course.

Jon Skeet
What do you mean by Client? I am just using a web browser with the url http://localhost:8080/login/user/pass.
Xaisoft
@Xaisoft, I believe Jon had it backwards, but the substance of his answer is correct. If you are just accessing it through a browser, then that is of course a GET request. By default, WebInvoke only allows POST requests, and so will therefore fail when accessed from the browser.
Kirk Woll
@Xaisoft, Kirk: Yup, I'd misread the question - I've now rewritten the answer to be a bit clearer.
Jon Skeet
This sounds counterintuitive though: WebInvoke by default is a POST, but by changing the Method to GET, I can essentially make WebInvoke behave like a WebGet.
Xaisoft
@Xaisoft: I'm not sure why that's counterintuitive. Think of WebGet as a specialised WebInvoke.
Jon Skeet
Thanks Jon, I probably am more confused because all of this is really new to me. As I get into it, it will start to become more clear.
Xaisoft