Context
I am new to WCF.
I was reading an article about message contract and found that WCF is sending message using SOAP.
My doubt is, if we are enabled REST in WCF service, then will it still use SOAP format for exchanging data.
In WebGet and WebInvoke attribute[which are for REST], we are mentioning the inputformat like JSON or XML.
Question
If messages are sent through SOAP, then why are those needed ?
If all message contracts are sent using SOAP format, then message contract should not work in case of webHttp binding.
The protocol format will depend on the binding you select. Here's a list of the different system provided bindings and the underlying protocol they use.
In WebGet and WebInvoke attribute[which are for REST], we are
mentioning the inputformat like JSON or XML.
If messages are sent through SOAP, then why are those needed.
If you use the WebHttpBinding which uses standard HTTP instead of SOAP then those attributes allow you to specify whether you want to format the requests using plain XML (not SOAP) or JSON.
Related
The WCF Web API returns data either XML or JSON based on the Accept parameter in the request header not considering whether we set ResponseFormat=WebMessageFormat.Json in the WebInvoke/WebGet attributes. Is this the correct behavior of the API or a bug?
WCF Web API ignores the ResponseFormat attribute. That attribute is just there because of an effort to be backward compatible with previous WCF REST efforts.
The returned media type is based largely on the Accept header sent by the client.
In this
post in answer was show that we can force service to return message in json. But wcf have feature that allows automatic convert return message in soap or rest format like json using few endpoints typed in config ? For example I set WebInvoke attribute on service and set two address for endpoint like serviceAddress/soap , serviceAddress/json and wcf choose good endpoint for specific format result?
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.
Consider this scenario that two WCF clients connect to one WCF service(server), this service will receive an object from one client and send it to the other one through some operation contract and client callbacks, both clients have the type for this object but we do not want the WCF service(server) to be dependent on this type.
The project is much bigger than this, but I wonder if you can send an object with an unknown type to a service and somehow receive it back on the other client. I saw this but it does not help me at all: Can WCF service transmit type (client doesn't know this type) information?
Thanks in advance.
You can do certain things with the "raw" Message data type - but it's really not pretty programming...
Read about it here:
How to pass arbitrary data in a Message object using WCF
WCF : Untyped messages on WCF operations.
Sending an "object" with unknown type is not possible in WCF because WCF requires a full compatibility with WSDL - and WSDL requires transparent type definition.
Having said that, if you use a type of object I believe there is a way for this to be loaded as a string and in WSDL it is defined as xs:anyType.
I personally would prefer defining the type as string and passing an XML which can be serialised using plain XML Serialization. I have used this in our company and it works really well, especially since we will be storing the XML as document in database.
I'm building a WCF service based on a W3C specification which defines a RESTful web service endpoint that accepts "application/x-www-form-urlencoded" post data. WCF doesn't support this type of message encoding by default and I have found a number of different examples of creating a contract that looks like this:
XElement Query_Post(Stream postData);
And then within the implementation decoding the postData stream using the HttpUtility.ParseQueryString method.
Does anyone know of a more strongly typed way of supporting "application/x-www-form-urlencoded" in WCF?
I would like my operation contract to be:
XElement Query_Post(string query, string [] params);
The best way is to use Stream like Raw HTTP POST with WCF or what you are saying.
The reason is because WCF abstracts all the communication-level physical layout stuff out from the service code. Ideally, you would want to make a service that could turn into SOAP or REST just by flipping the switch.
To support it natively, you probably have to extend WebHttpBinding or make your own binding and implement custom encoder. This is symmetric to the output like the linked post says. You have to twist its arms to get WCF to output non-XML/JSON stuff.
The WCF REST Contrib library enables this functionality:
https://github.com/mikeobrien/WcfRestContrib
It includes a POX formatter and form url encoded formatter and allows you to easily create your own. Formatters are mapped to mime types and automatically selected to serialize/deserialize the entity body based on the content type and accept headers.