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
Related
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.
I am using wsfTestClient to debug a c# wcf service program. my interface for this function has
[OperationContract]
[WebGet(UriTemplate = "AddCsv?fileLoc={fileLoc}", BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Json)]
void AddCsv(string fileLoc);
and the corresponding class is
public void AddCsv(string fileLoc)
{
List<Entity> listOfEntries = LoadCSV(fileLoc);
PutList(listOfEntries);
}
I have a breakpoint at the declaration of the AddCsv method and I look at the fileLoc variable and it is null. Why is this acting this way? fileLoc is a directory location.
Here is a screen shot of the wcftestclient
WCF Test Client does not work for non-SOAP endpoints (a.k.a. WCF REST services). Since you decorated your operation with [WebGet] I'm assuming this is the case for you. The issue is that non-SOAP endpoints do not expose their metadata so that tools such as WCF Test Client (or svcutil) can know how to call the service.
For more information, check the post Mixing Add Service Reference and WCF Web HTTP (a.k.a. REST) endpoint does not work.
I created a WCF self hosted web service. Here are my serviceContract and OperationContract in Instace class:
[ServiceContract]
public interface ISwiperWS
{
[OperationContract, WebInvoke(Method = "GET", UriTemplate = "/getstatus?callback={Callback}", ResponseFormat = WebMessageFormat.Json)]
String getStatus(String Callback);
}
TestWS.cs
public String getStatus()
{
return "true"
}
I am accessing the endpoint of this web service from JsonP written in GWT
String url = "https://somedomain.com:8083/getstatus";
JsonpRequestBuilder jsonp = new JsonpRequestBuilder();
jsonp.setTimeout(600);
jsonp.setCallbackParam("callback");
jsonp.send(url);
I create a setup project and installed it on different-different machine. Whenever i am making a request to web service endpoints from JsonP It is showing an strange behavior. In some machine i am getting an expected response where as in some other machine it continuously showing an error i.e. 405-method are not allowed.
I searched it for and make change according to them but nothing works for me. Please suggest me a solutoin
May be: I believe it had something to do with your jquery ajax call using jsonp. If you are going to change it to just json the post will work..
I have a WCF Service that return JSON format Data. When i use a Web Browser i can easily see the result but when using Jquery getJSON i cannot get it to work. i can see in fiddler that it is returning the data but in firebug it shows with red font and empty response.
here is my WCF service
[OperationContract]
[WebInvoke(Method = "GET",
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Wrapped,
UriTemplate = "GetUrl/{iType}")]
String GetUrl(string iType);
public String GetUrl(string iType)
{
return strurl;
}
MY JSON call looks like this
$.getJSON("http://localhost/UrlSvc/UrlService.svc/GetUrl/1",
function (data) {
console.log("Data JSOn Got");
$.each(data.items, function (i, item) {
console.log("Data Received");
});
});
when i just put that url in browser i get this below in response as expected
{"GetChartUrlResult":"ulr_fdba9bc2-7ff7-467f-a6e0-6f4d234169d2.png"}
BUT getJSOn returns Empty Response as seen in Firebug with Red font on the url Itself.
this is a cross domain call and i have enabled cross domain it WCF
Browsers do not allow cross-domain AJAX calls and stop XMLHTTPRequest's from happening to any domain but the one that loaded the containing script or page.
To get around this, you can use JSONP calls that wrap the AJAX response in javascript. You add the the following query string entry to your request:
callback=?
Also, note that if you are using WCF, you will need to enable JSONP in your service. You do this by setting the crossDomainScriptAccessEnabled attribute to true in your to your config file:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
<standardEndpoints>
<webScriptEndpoint>
<standardEndpoint name="" crossDomainScriptAccessEnabled="true"/>
</webScriptEndpoint>
</standardEndpoints>
</system.serviceModel>
More information about JSONP and WCF can be found here.
If the call is cross domain, you have to use jsonp. You can use it with $.getJSON by adding ?callback=? to the URL (depending on the server-side API). Make sure that your API does support emitting the callback appropriately.
Documentation here: http://api.jquery.com/jQuery.getJSON/
Sorry to be late to the party - you DO NOT have to use jsonp, i use WCF with angularjs, jquery, mobile apps, etc - and never use jsonp.
Just decorate your class and properties like the following and it will serialize.
[DataContract]
public class MyCustomClass
{
[DataMemember]
public string Name { get; set;}
}
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