Architecture Question Regarding WCF

[michaelkrauklis]

Hello All,

I'm currently developing an API that will be used by our current clients, as well as future clients yet to be defined. We would like this API to have the ability to be secure, so the built in features for WCF seemed like a natural fit. Unfortunately our current clients are running on non-Microsoft platforms and will have trouble with something like wsHttpBinding. I don't want to spend my time debugging their platforms so I'm hoping to make our interface flexible and accessible to different clients, even at the cost of some security.

That being said, my first thought was to offer up two endpoints: one with a custom/basicHttpBinding, and one with wsHttpBinding. Each of these exposes several variations of operation, some expecting a GET, some a POST with the URL parameters in the HTTP envelope, and others with the XML representation of the request object in the HTTP envelope. This is exacerbated by the varying return types available. Currently I am exposing an XML response that actually contains a status, error message, etc, or a straight string that is a representation of the a fore mentioned structure. In short, this is not a viable long term solution as the API gets more and more complex.

My thoughts are as follows:
* Get rid of the string response and always return structured XML. I say this only because I've been unable to figure out how to return raw text as a response, so since I'm already wrapping with the string element I may as well return the entire response in a more structured fashion.

* Offer up three versions of each operation:
Basic HTTP GET [Request:Url-Params;Response:Xml]
Basic HTTP POST [Request:Xml;Response:Xml]
WS HTTP [Full handshake and security]

I'm thinking this should accommodate my simplest clients, but allow for a more robust solution for those who require it.

Soooo, I've only really been digging into WCF for the past two days and I'm probably going about this all wrong. I'm looking for advice on my methodology and/or my approach. I have looked all over the place and there is plenty of information on deciding what binding should be used, but nothing regarding the decisions to be made when multiple bindings may be required. Maybe multiple bindings is a bad idea to begin with. Any advice will be greatly appreciated.

Thanks,
Mike K.

"If debugging is the process of removing bugs, then programming must be the process of putting them in." --Dykstra

 

[chiph]

If your callers are multi-platform (Java, PHP, Ruby, etc) then going to the lowest-common denominator is the way to go. That would be the basicHTTP binding, and restricting your parameter datatypes to fundamental types (integers, strings, datetime, etc).

Passing an XML blob as a string parameter is workable, but be aware that it will increase your data transfer times, as all those angle-brackets have to get translated into < and > tags because they're being nested inside a SOAP (XML) message.

So far as extending your API later, there's a couple of approaches:

1. Use an XML blob that has an xs:any tag in it (validating these is a ... challenge)

2. Have different API sets for each release in different virtual directories on the web server. So the URL for this month's release would be

http://www.example.com/2009/02/MyWebService,

and next month would be

http://www.example.com/2009/03/MyWebService

Since you're limited to fundamental datatypes, you can't do something like pass a structure with a leading version indicator.

Chip H.


____________________________________________________________________
www.chipholland.com

 

[michaelkrauklis]

Thanks Chiph!

I think ultimately we've decided to do more of a REST style service for the less technical folks, secured with SSL. We'll also make available a webHttpBinding for the WS-* folks. I think this should cover all our needs.

Thanks again,
Mike K.

"If debugging is the process of removing bugs, then programming must be the process of putting them in." --Dykstra