I am a little confused by web services and how they're used. I have created a WCF web service that has an operation contract taking 3 parameters. Then I interrogate our database and return an object matching the data contract. All seems to be good. But how does a third party use our web service? What do I need to provide to them in order for them to use it? Do I need to put a link on my web site? What should that link look like? Thanks!
For third party, you need to share:
Path of Hosted service: it is needed to add service reference.
Information about Service Contract methods: documentation of what exposed operation contracts actually do.
DataContract dll: Only if you are reusing DataContracts.
Some information some times needed to add endpoint if you have to customize default endpoint for client (something like service timeout, packet size etc).
Hope it helps.
Related
We are looking for a solution to consume a REST full service dynamically in C#. It is something like Wcf test client. In our application, user should be able to provide a service url and then select the required data to be used in the application.
Normally, we will get the WSDL in case of SOAP based service, that describes all about the service, like available methods, parameters to be passed, response type, etc. We, then can use the response, probably using reflection if we execute it dynamically.
How can we achieve the similar information if the services are RESTfull? How do we know what type of data it returns? What is the schema? etc.
I found something called WADL and RSDL can be used to know about the RESTfull services. Do all the REST full services always provide that? If so then how? If not then how will I get to know about the services?
Please note that in our application, we want our user to register any RESTfull service at runtime and consume the response in the application, so we don't want to code for each type of services.
WCF support dynamic discovery in case SOAP. Does it support something similar for REST?
I have some clients calling my asmx service and I figure out to change my asmx to a Wcf service.
How can my asmx clients call to my Wcf service without modify the client application?
Maybe just a few changes in the config file...
I can't expect than they compile their applications.
The following article illustrates a detailed guide on how you could achieve that.
You need to support basicHttpBinding in your WCF server and provide new URL to your basicHttpBinding endpoint to callers.
Callers only need to change URL they use.
Everything should happen behind the scene for them.
I am having an Existing ASMX webservice in Production. I need to add RESTFul capabilities to the same for Rest Clients.
As per my understanding it must be as simple as adding a HTTPHandler (restversion.ashx) implementing IHTTPHandler and calling Business methods while serializing the return objects to XML or byte Stream. Which will be received and interpreted by REST Clients.
Though, while searching on the similar topics, it is not recommended and Can't be done.
Please suggest me..
I would recommend using WCF Web API. There are several tutorials at the end of this page. As you can see it is pretty easy to build simple RESTful service. There is also built in test client so you can test your REST service using your browser.
Assuming you want to continue your investment in the legacy ASMX technology, you can create a new WCF REST service, and have it call the existing ASMX service as a client, in order to perform its functions.
I want to architecture our software so that we can expose our API logic using WCF (SOAP and REST).
Im confused as to whether I have to use ASMX files if I want to do SOAP services, or whether .svc file can still do SOAP service?
Yes you can. You have to expose a SOAP end-point for your WCF service. This MSDN post has an example.
Your svc file can provide the restful interface you are requesting. You just have to do a little configuring within your web configuration file, and decorate the svc class with the attributes to describe the behavior of our restful url.
here is a great article going over the steps:
http://www.dotnetfunda.com/articles/show/779/simple-5-steps-to-expose-wcf-services-using-rest-style
With a reference to my previous question, I would like to know how would I extract information of a WCF service from a client application to know what methods/types are exposed if the service exposes only one endpoint that uses webHttpBinding?
Just to summarize, in my previous question, I came to know that an endpoint using webHttpBinding does not get exposed in the generated WSDL because it would be a JSON endpoint and is just not compatible.
WebHttpBinding is a REST-based binding - REST does not expose metadata like WSDL/XSD contrary to SOAP.
There's no way to extract the metadata from a REST endpoint at this time. There are some efforts under way to establish a similar construct for REST called WADL (Web Application Description Language) - but that's nowhere near standardized yet.
For now, with REST endpoints, you have to either figure it out yourself, or you need to have some documentation provided by the service provider on e.g. a static HTML page or something.
.NET 4 does provide some level of an automatically generated help page - see this blog post or the MSDN docs for more info. But it's still nowhere near as formalized and machine-interpretable as WSDL/XSD.
I wonder why the REST samples tell you to expose a MEX endpoint at all. It is not needed and here is how to cleanly remove it:
Remove MEX endpoint from the service section of the config file.
Remove service metadata enabled line in the service behaviour section of the config file.
Edit the Visual Studio project (assuming it's a WCF service library) and remove the line:
<StartArguments>/client:"WcfTestClient.exe"</StartArguments>
If you have other non-rest services you will want to leave the last 2 parts present. You must remove the WCF Client when disabling MEX otherwise it will complain during debugging if it cannot enumerate any services in the project (regardless whether they have any useful metadata or not).