Hey Aral, > Personally, I don't see the use of consuming web services on the > client. First off, you cannot have any sort of hidden information in > there so that rules out using this for commercial web services where > you have a secret key/developer key/etc. unless you want the world to > know it and use up your quotas. If you're not going to use it for > third-party services, then you're probably going to use it to talk to > your application server. In which case, why are you using a heavy > protocol like SOAP when you could be using Remoting, REST or even > good-ol' fashioned variable-encoded strings over HTTP? If you are > using third-party web services, you should really be consuming them > on the server side and implementing security, redundancy, etc. there.
I disagree with your blanket dismissal of SOAP. Yes, it's heavy and not suitable for all situations, but when you need to send complex object back and forth to a web service then there's nothing that beats SOAP. It is, as with everything else, a case of using the right tools for the right job. In this broadband-enabled age the amount of information being sent and received is becoming less of a problem, and then you start to look at things like easy of use. If the WSDL file already exists, and you can use a tool like David's to create the relevant ActionScript classes, then a SOAP web service is easier to set up and more robust than manually handling the response from a REST API. Steve -- Steve Webster http://dynamicflash.com _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
