Is it possible to consume a JSON enabled WCF Web Service from a standard Proxy Client (i.e. not JavaScript)?
Basically I want to minimize the payload size between 2 web services.
Yes, it is, if the service interface definition on the client side is setup correctly (i.e. the RequestFormat/ResponseFormat properties of the WebGet/WebInvoke attribute on the operation contracts are set to Json. Also remember you'll need to use the WebHttp or WebScriptEnabled behaviors on your client.
Notice that JSon won't necessarily be most efficient given the current implementation in WCF; there are definite trade offs you'll be making. There's a good overview of it on this article.
Related
Is there some way that I can get list of all the WCF restful services operations at client side( something like helpEnabled).
I tried to use http://servername/service/help, but it returns complete html. I want to get the operations suported by the service in the program.
I want to list all the operations supported by the service.
Is there any way to do it?
The short answer: It depends on what the creator of the service you are trying to consume has exposed.
There are two sides to this particular "issue". One side states that you should be able to hit a GET endpoint and then follow links (often ATOM PUB, esp. for the REST in Practice crowd). The other is pushing WADL, a REST analog to WSDL (SOAP Services). In the first camp, there is no map and the service works more like a website. In the second, you have a description of all services.
Is it possible to use oData with a WCF service application but not use WCF Data Services?
It will be great if someone could shed more light on oData. I have done some Googling on this topic, but whenever I search for "wcf odata", I get information about WCF Data Services.
Any help/links will be appreciated.
WCF Data Services is the Microsoft implementation of the general OData protocol. As such, only WCF Data Services are / support / implement OData - a "normal" WCF service does not (and can not).
You might need to elaborate exactly why you feel the need or urge to use OData but not use WCF Data Services. What's the issue / problem you have with that setup? WHY do you want to use only a "normal" WCF service??
Update: ok, so you want to have services that expose data in different fashions and with different methods. What you could do is create a regular WCF service that's exposing both SOAP endpoints as well as a webHttpBinding REST endpoint. This will work - but then it's a "regular" WCF service, with methods that take parameters and return some data structure. This is not WCF Data Service (OData).
OData is more of a "here's my data collection, you can browse around in it" kind of approach - it's more about exposing an entire data model to the outside world using REST. This doesn't mix and match with SOAP - which is a lot more procedure-oriented, e.g. LoadCustomer, SaveInvoice and so forth.
So while it's absolutely possible to have procedure-oriented WCF services exposing both SOAP and REST endpoints at the same time, I don't really see how you can mix and match the "expose-this-resource" kind of approach for WCF Data Services / OData with a SOAP binding - this just doesn't work, I believe.
So if you must expose your data model of WCF Data Services (OData), you will need to author a second, pretty different looking regular WCF services for the SOAP clients, that might be based on the same data in the end (access the same database, for instance), but it's "face" will look quite different.
There is a new(ish) project from Microsoft called WCF WebApi (NuGet Package), which is simplifying doing RESTful WCF. It really takes to heart the "Representation" part of REST, so that you can expose your data in many representations (JSON, XML, oData, PNG, etc) based on content negotiation (or optionally whatever convention you want) all from the same service contract operation. Currently baked into the framework is the ability to support oData GET queries, by simply returning a collection .AsQueryable().
While this isn't a pure WCF/oData solution, as your question is speaking to, I thought I would mention the project in case it fit your specific requirements. The current Go-Live licensing might prove prohibitive, as might the "preview" status of this code; but if not, this may be a solution for you.
* UPDATE * This project was rolled into ASP.NET (usually in conjunction with ASP.NET MVC) and is no longer under the WCF team. The new product is called ASP.NET WebAPI.
I'm building a WCF SOAP service at the moment. I will, of course, need some authentication on the service.
Reading this very helpful blog post says that to use the built-in authentication points requires that the endpoint use the wsHttp binding.
This would be fine if I could guarantee that users would be communicating with the service through a client based on the meta-data exposed by WCF (basically, something like a client written in C# with a web service reference). However, I can't guarantee this!
I will still need to allow users to communicate with just raw (unencrypted) XML.
So, questions:
Does the wsHttp binding still allow for raw XML input?
If not, would I be wiser to
Implement two separate authetication points? One for raw XML input and one for encrypted input
Or
Allow input from wsHttp to fall back on some in-method validation that would be shared with the raw XML input?
Is it wise to allow users to pass their credentials inside a raw XML request?
EDIT: It sounds like I miscommunicated or misunderstood something in my original post, so here I will clarify what I mean by "raw XML".
By raw XML, I mean just the SOAP packet and the accompanying HTTP headers - as I might send from soapUI or Fiddler. As I understand it, messages over the wsHttp binding are encrypted when a client is generated from the WSDL (for example, in C#).
If this is not the case, then how would I go about attaching the same sorts of credentials to a raw XML (for want of a better term) request as I do a request run through a client? Are they attached as HTTP headers? XML elements in the SOAP envelope?
wsHttp is a SOAP binding, which means that your content gets wrapped in a SOAP envelope, possibly with headers relating to the message and various WS-* specifications being used.
I would ask why you need to support raw XML? Most platforms today support SOAP messaging and the whole idea of SOAP is to provide interoperability between different platforms. On most platforms it is as easy to develop a SOAP client as a raw XML client. In most cases, it is simply a case of taking the WSDL and generating a client. If you want to use standard facilities like authentication and message encryption then this is a much better way to go.
There are currently no hooks to do interoperable authentication for raw XML. You will have to come up with your own mechanism to do this and it will be non-standard. For your web service users, this means it will be probably entail more development effort than if you just went with SOAP.
I am going develop a WPF windows based application. I want to work with Entity Framework Self Tracking Entities and WCF. I was wondering if using Json is possible/recommended? If yes, please assist me; is there any tutorial that can help?
You can use the DataContractJsonSerializer to serialize the messages. You will have to use a REST based service (WebHttpBinding) as SOAP mandates XML as the message payload.
You can tell WCF to use the DatcontractJsonSerializer on the service side by settings in the WebGet and WebInvoke attributes but on the client side you will have to manually use this serializer as REST doesn;t have a metadata standard and therefore you have to create the requests and manage responses in a more manual fashion
Here is a reasonable guide to using Json and REST support in WCF
However, what is your driver to using Json? WCF is much more geared to SOAP based interaction currently (although the WCF 4.5 WebApi is going to address that to quite a degree). As your client is WPF you don't seem to gain alot from using Json
I'm looking at creating a data query WCF service over a slow satellite connection and I really like WCF Data Services. The problem I see is that HTTP is a very verbose format and since everything I'm doing is internal and .NET, is it possible to use NetTcpBinding instead to reduce some of the overhead?
Is this even possible? Advisable?
While researching this on my own, i ran across the MSDN article on Self-Hosted WCF Data Services. This article notes that you can host the service with DataServiceHost which still requires HTTP (it's derived from WebServiceHost).
But you can also roll your own host using IDataServiceHost. Here's an excerpt from the MSDN article:
For cases where the WCF host
implementation is too restrictive, you
can also define a custom host for a
data service. Any class that
implements IDataServiceHost interface
can be used as the network host for a
data service. A custom host must
implement the IDataServiceHost
interface and be able to handle the
following basic responsibilities of
the data service host:
Provide the data service with the service root path.
Process request and response headers information to the appropriate
IDataServiceHost member implementation.
Handle exceptions raised by the data service.
Validate parameters in the query string.
The article seems to suggest that MS has properly segrated data-service responsibilities from network interface responsibilities. If that's so, then I should be able to write a NetTcpDataServiceHost. Has anyone ever written a IDataServerHost? Any suggestions?
No, WCF Data Services are built on top of REST, and REST itself is very intimately and completely based on the HTTP verbs like GET, PUT, POST etc. - you cannot run those over NetTcp, since those are intrinsically tied to the HTTP protocol stack.
Maybe there are other options for you to reduce the data being transmitted? Tweak your objects - trim the fat, if you can - both on the number of rows retrieved at once, and the number of attributes/data fields transmitted. That's probably you're most promising approach.