Probably missing something very basic. I created a WCF 4.0 Rest Service. It works no problems when I'm hitting the url from a browser and I'm getting back what I want.
But now I want to use that service from a client mvc application (it will also be used by other non .net platforms which is why it's a rest service in the first place).
Problem is how do I get a service reference to it so I can start to use it in my c# code? With the new minimal WCF .net 4 config approach and no interface for the service contract, I don't know how to specify a mex endpoint. Ultimately I don't want a mex endpoint in production, just during development. I would love to be able to specify that all my services (around 10 in one application) have endpoints with one tiny piece of config that vs2010 .config transformations just rips out when I publish.
Stop. REST service doesn't use metadata. Metadata (Mex endpoint) are only for SOAP services because WSDL 1.1 (the only version supported by WCF) is able to describe only SOAP service. WADL or WSDL 2.0 is able to describe REST service but non of them is currently supported by WCF.
REST service is consumed by using WebRequest directly or by building ChannelFactory on top of shared contracts. Both methods are described here. Other method is to use HttpClient from REST Starter kit (former API). The problem with Starter kit is that it has never reached RTM (it was replaced by WCF 4). Instead of metadata endpoint WCF 4 REST service offers help page where all operation are described. When using WCF 4 REST template the help page should be already turned on - just add /help sufix to address of your service. Here is another article about building REST clients.
Related
I have created a WCF service and hosted it through self hosting. This service doesn't have any metada published.
First Question
Can I consume it through Visual Studio, Add Service Reference? Hopefully not.
Can I consume it by creating manual proxy, i.e. ChannelFactory<ServiceContract>....?Hopefully yes.
Now in the second scenario, the client must be .Net, right?
So it implies that, to consume a wcf service on a non-.net platform, we have to expose its metadata?
Can't a WCF service without metadata, consume by Ajax client, or say Java client??
There are 3 options to consume a WCF Service:
If the service exposes a WSDL use "add service reference" from VS (or an equivalent from another platform). Note that if you do not want to expose the WSDL you could expose it just temporarly, save the WSDL in a file, and then send it to user in any platform to generate proxy from it. You can turn off the WSDL immediately after you save it. Also note that even if the WSDL is not exposed still you need to protect the web service from unauthorized access.
If this is a .Net client it can compile with the same Service Contract assembly and use ChannelFactory etc.
Any platform can send raw soap message (e.g. XML) to the service. Of course they need to know what is the right format. A WSDL can help but even without it if they have a working sample they can imitate it.
WCF provides REST (Representational State Transfer) support to consume it by non .NET client like JavaScript (AJAX), java, Objective C, web browser, etc...
Basically WCF REST is exposes methods and transferring data over the HTTP protocol and it supports all HTTP operations (GET, POST, PUT, and DELETE). This feature is making it platform independent as well as it doesn’t require metadata exposed.
Please refere below links to get more about WCF REST:
An Introduction To RESTful Services With WCF
WCF REST Programming Model Overview
WCF Rest vs. WCF SOAP
Create RESTful WCF Service API: Step By Step Guide
I have two instances of VS2010 running on same machine.One VS instance has a WCF service with basicHttpBinding.
Now as i have read in books, for calling this WCF service with basicHttpBinding, i have to Add a Web reference to it rather than Service Reference.
I ran the project containing the WCF service and from other VS instance try to add a Web reference, this is the URL which i gacve(I got it from WCFClientHost )
http://localhost:8732/Design_Time_Addresses/WcfServiceLibraryBasicHttpBinding/Service1/mex
But i get Http 400 error everytime i try to add the WCF service.
Please let know what i am doing wrong.
You should keep two things apart:
Add Service Reference adds a service interface based on the .NET 3.0 and up WCF runtime. It supports all WCF bindings - including basicHttpBinding
Add Web Reference is the old-style, .NET 1.x/2.x method of adding a reference to an ASMX web service ("ASP.NET web service"). This technology is outdated, and has been fully replaced by WCF as of .NET 3.0. ASMX only ever supported what is more or less equivalent to basicHttpBinding.
The ASMX technology is outdated, and you should only ever use this if you really can't make WCF work (but in my 3 years of writing and consuming a plethora of web services, I have never seen such a case) - avoid this unless you absolutely can't make WCF work - for whatever weird reason that might be...
The link you gave to the CodeProject article has a entirely plain wrong statement that you need to use Add Web Reference for basicHttpBinding - that is just plain NOT TRUE.
I have built a web service (WCF) as part of our company product, to support mobile devicies. The service is exposed via SOAP and is consumed by Android and Windows Phone 7 clients. Now we are spreading and need to add support for iPhone clients and those lazy iPhone developers are complaing, that they won't use SOAP, because its terrible, microsoftish, bloatware and there is no sufficient framework for that, etc etc and JSON ftw!
As it is WCF it was easy to create json api for this web service (new interface and little changes in web.config, love WCF!), the only problem is that I am using the built-in WCF Authentication service for authorization and this service is of course exposed via SOAP and I didn´t find a way to make it REST with json. So is there a way to somehow make it RESTful and consume/respond json?
My actual plan is to make another auth service, that will internally just call the existing WCF one via SOAP, but I don't like this workaround. I assume that, if there is not a way to make the WCF one RESTfull, later or sooner, I end up writing the auth service, which in my opinon will not be that hard.
Darin Dimitrov answered a question about supporting XMLRPC interface (bindings) under a WCF .net web service. In his response, he explained to add references to Microsoft.Samples.XmlRpc and TinyBlogEngine.
Why is the TinyBlogEngine engine needed?
How can I take a working .net 4 WCF web service and add support for XMLRPC without making it a blog application?
Why is the TinyBlogEngine engine needed?
TinyBlogEngine simply contains the WCF web service code which you could replace with any implementation you like (blog or whatever). This could be an existing web service you already have. Microsoft.Samples.XmlRpc is what enables a XML RPC binding to an existing WCF service. You just need to have this XmlRpcEndpointBehaviorExtension I've shown in the post if you want to be able to configure the RPC binding via web.config.
I'm developing a .NET 2.0 client application that needs to connect to a WCF service. I add a web reference to a basicHttpBinding WCF service that we've developed and VS creates the proxy class and the config paraphenalia which is fine. The problem is that I only want to use a small fraction of the methods that the WCF service implements and not carry around the extra implementations that the client app doesn't need.
I was thinking of creating a different basicHttpBinding endpoint and put the methods there. Is there a way for only one endpoint of a WCF service to be referenced by a .NET 2.0 project?
Regards,
Frank
When you add a web reference to a service, you always get all the service methods. It's the service (implementation) that defines the scope of what ends up in the WSDL.
The only option to limit the scope of the method your client generates would be to create a second WCF service on the backend, which only implements those few methods that you want in your client - just having a second endpoint won't really help.