I remember back when I first started working with web services how happy I was that .net created it’s own client proxies. Hitting any web service that exposed a WSDL was a snap in .net, I didn’t need to know anything about SOAP or even XML for that matter. All I need was to created my trusted web reference and off I went consuming web services both near and far.
Now later I came to realize that, in .net 2.0 anyway, all the services and their arguments were created in proxies with their own name spaces, and the proxy arguments had only public fields, not properties so couldn’t bind to them. This prompted me to create wrappers around all .net 2.0 services to transform arguments and returns types to common objects and such. Windows Communication Foundation (WCF) came along and took care of all these issues for me. Still, even with the introduction of WCF I was pointing my trusted IDE at a WSDL for the most part, and it was doing it’s client proxy magic. I still needed no jedi like WSDL knowledge, although to configure WCF I know actually did need to know something about XML (especially setting up certificates and error handling).
Now we come the world of Restful services. No more WSDL, but also, no more proxy magic! I can’t point my trusted IDE at a URL and have things done for me. Now I have to actually do things for myself, sort of. It seems most publishers of Restful services (Amazon, Netflix) give you documentation about their API, so you can consume their services directly yourself, but they also provide client implementations in popular platforms, so you don’t have to write code against the restful API yourself if you don’t want to. It’s probably better since I think I have more faith in client proxy code created by the publisher of the Restful API then I do with the code generated by my trusty IDE. Plus I can look at and makes sense of the communication in an interaction with a Restful API. SOAP was always a mystery, especially when it came to authentication.
Now as we start publishing Restful services ourselves on my current project, I’m eager to publish client proxies for those that will consume them. I Feel like I’m returning the favor of the Restful services we’re consuming by using client proxies provided by the service itself. We are using WCF to host or Restful services and that in itself has some interesting nuances. Microsoft publishes a Restful WCF starter kit, which is useful to get up something that requires very little configuration. We quickly ran into problems when needing to configure our service to use HTTPS and authentication and ended up abandoning the starter kits base service object WebServiceHost, for the traditional WCF ServiceHost configured with a WebHTTPBinding and WebHTTPBehavior. Using these allowed us to configure our Restful Services with the same XML constructs we used in our SOAP based WCF services.