views:

21

answers:

2

I'm working with a .NET based Web Service where some of the API calls can be accessed via HTTP POST/GET but on others only SOAP 1.1/1.2 are available.

The company that has developed the API have come back to me have said the following and I was wondering if he's trying to pull the wool over my eyes or whether he's speaking the truth. His response doesn't sit comfortably with me so I thought I would try and check but haven't been able to find an answer.

I was thinking it is very odd as I have not specified anything on the other methods in order to make them accessible using the HTTP Post or HTTP Get protocols. I have globally set it so that they should all be accessible. I have been looking into this, and it seems that the HTTP Post and HTTP Get protocols can only be used with methods that use simple types, e.g. where a method takes and integer parameter. The methods you have listed below take more complex objects, e.g. nullable type or custom objects. However the SOAP protocol can be used with this complex methods.

A: 

His explanation is correct. POST/GET only permits typical primitives -- int, string, bool, etc. Or rather, parameters that can be interpreted with simple name/value pairs. The SOAP protocol handles the XML side of web services in .Net (sounds like he's talking about legacy ASMX services.)

UPDATE: a little context here. It sounds like your contact doesn't know much about .Net web services, so while his description is based on what he knows, it's certainly not a limitation of the environment; he just needs to do a little more work.

jro
Just so I'm clear on what you're saying can I give you an example? One of the API calls is to return a home address by providing a membership number. The return value should be an XML of the address fields held for that individual. Would that fit into the incompatibility you refer to?
baswoni
No, the return value can certainly be complex XML. SOAP comes into play with complex parameter structures. And, it sounds like your contact doesn't know anything about .Net web services beyond the out-of-the-box ASMX variety. These limitations can certainly be avoided with customization or using the features in WCF.
jro
A: 

He is incorrect. You can use the DataContractSerializer to send and GET complex types.

Here is some code I used to answer another question recently:

In order to POST parameters, you need to serialize it using the DataContractSerializer. e.g,

On server:

[OperationContract]
[WebInvoke(Method="POST",UriTemplate = "/foos")]
void PostFoo(Foo foo) {}

On client:

var foo = new Foo();
var content = HttpContentExtensions.CreateDataContract<Foo>(foo);
var client = new HttpClient("http://example.org/service.svc/foos");
client.Post(content)

The client code uses the Microsoft.Http library that is found in the WCF Rest Starter kit.

Darrel Miller