Develop Reference

Send some values through url to .svc service

I have a service on my website that works well but now I want to pass some values through url. Is this possible?
Service url: http://example.com/Service.svc
I use it like:
ChannelFactory<IService> factory = new ChannelFactory<IService>("myKeyBinding");
IService service = factory.CreateChannel();
service.Method(value);
What I want is: Service url: http://example.com/Service.svc?some=value&another=value
And use these values on my website.

WCF do support restful behaviour. It's easy:
First mark your contracts with WebInvoke
[WebInvoke(UriTemplate = "Method/{some}/{another}", Method = Get, ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]
string Method(string some, string another);
Create a new ServiceBehavior with following metadata:
<serviceMetadata httpGetEnabled=”true”/>
Create a new endpoint based on this behavior. It should have binding as wsHttpBinding
Now, call your service like:
http://example.com/Service.svc/Method?some=value&another=value

REST vs SOAP WCF Service - is there a downside for using both

When developing my WCF Service I originally planned using REST but later found out it will be called using SOAP. I have decorate my methods with both SOAP OperationalContract and REST WebInvoke but created only SOAP endpoint.
public interface IMyService
{
[OperationContract]
[WebInvoke(UriTemplate = "GetData/{ID}/{Name}", Method = "GET",
ResponseFormat = WebMessageFormat.Json,
RequestFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.WrappedRequest)]
string GetData(string ID, string Name);
}
My question is what are the possible implications of using both OperationalContract and WebInvoke, if any? Are there downsides?
Should I keep it as it is, in case later I might need to add a REST endpoint? Or should I remove WebInvoke?

My question is what are the possible implications of using both
OperationalContract and WebInvoke, if any? Are there downsides?
No, there are no downsides, other than you are adding code which may never be used.
Also, for your info, OperationContract is for all WCF operations, not just for SOAP operations. You need it for REST also.

How to call a class method using ajax in c#

I have a class in my c# project. Let's say Sample.cs
I want to call it's method using ajax, but don't know how to use class name in url of ajax, I am doing like this, but it's not working
$.ajax({
type: "POST",
url: "Sample.cs/MethodName",
data: '{Id: "' + Id + '"}',
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function (response) {
}
});
Please Help Guys...

If you directly want to call a method of a class, you cannot.
You can only make HTTP requests calls.
If you are using, MVC, what you can do is that create an Action method with return type as JsonResult, (as from you snippet, it looks you are expecting json response) call your method from this action method and return the same. Or you can create WebApi services and call that method within the ApiController method.

You can also create a WCF Rest service and call it from your js.
You create a method in an interface in C# which will react to your Http request
Here's an example
[OperationContract]
[WebInvoke(Method = "GET", //React on GET method
ResponseFormat = WebMessageFormat.Json, //Return Json format
BodyStyle = WebMessageBodyStyle.Wrapped, //Wrap request and response
UriTemplate = "login/{id}/{mdp}")] //Template Uri
bool Login(string id, string mdp);
This method will be called if you receive a GET method on an url like
SERVER_NAME/login/myId/myPassword
Note : all your parameters must be of type string
If you don't know what is a REST service here's some links
Wikipedia
If you want to learn how to create a REST webService in C# :
codeProject
Sadly I don't have enough point to post more link...
Hope it helped !

Customized message for endpoints not found in WCF Rest Service

I am using WCF to create a ReSTful service. Say my OperationContract is like this:
[OperationContract]
[WebGet(
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Wrapped,
UriTemplate = "GetItemList/{token}/{value}"
)]
Stream GetItemList(string token);
So when I call http://example.com/Service1.svc/GetItemList/myToken/myValue the service will be called.
Now I want to write a default method saying something link, 'No Method/End point exists', wen the user calls
http://example.com/Service1.svc/GetItemList/myToken/ or
http://example.com/Service1.svc/GetItemList/myValue/ or
http://example.com/Service1.svc/GetItemList/
How can I implement that in my code?
Right now what I'm doing is like:
[OperationContract]
[WebGet(
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Wrapped,
UriTemplate = "GetItemList/"
)]
string ValidateItemList();
[OperationContract]
[WebGet(
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Wrapped,
UriTemplate = "GetItemList/{Val1}"
)]
string ValidateItemList(string Val1);
And in the function, I just return a string saying "No method Exists".
Is there a better way? Can I customize error messages, for urls that are directed to my service? Say, a common message for all non existing url requests, that are directed to my service?

Basically, the architecture of WCF attempts to abstract the low level components of any protocol (in this case http) away so you don't have to worry about these types of details. Unfortunate;y, that engine does not expose a nice way to handle the request's that the engine cannot route correctly.
In this case, the URI cannot be "dispatched" to the correct contract implementing class. the engine has these wonderful components called, wait for it, Dispatchers, which can be customized within the wcf framework, either by configuration or programmatically. The problem is that they are a serious pain to implement. I have implemented the unexpected message dispatcher in my answer to another question, listed below:
Handling Invalid URI passed to a WCF service
Let me know if you need any further information!

I didn't find any feasible solution for my above problem. But I have found an alternate option. With VS 2012, Microsoft has released ASP.NET Web API. Which, they say, is the next version of WCF Rest. So in thet, you could handle these situations very easily. We can use the routing method in it.
Anyone intrested for that solution, can look into this post for a head start: http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-in-aspnet-web-api

Why does the WCF 3.5 REST Starter Kit do this?

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).

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.

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.