On Fri, May 24, 2013 at 8:47 AM, Paul McNett <[email protected]> wrote:
> \ > That's pretty funny. SOAP made something elegantly light and simple (http > request and > response) into something needlessly heavy and unwieldy. Maybe it was a > great design > for something, somewhere, but definitely not for web services. > SOAP is early binding between apps that communicate over the internet. The WSDL defines a _fixed_ interface: what's submitted, in what format, with basic validation of structures (think "strong" vs. loose typing). "Strong" interfaces mean both sides can program with strong expectations of what is submitted and all possible formats of what can be returned. They make solid interfaces. They also make unchanging interfaces, brittle ones that break if either producer or consumer try to change anything. XML-RPC and similiar APIS have a more relaxed attitude, that trades the security of all possible interactions being pre-defined with the advantage of being able to add new functions, features and return values without breaking the older interfaces. The downside is when you add a new interface you don't have a automated "discovery" mechanism for others to discover your new function call or return parameter. Think of adding a weather station to your network. You buy the cheap one to start, and create an API that returns the temperature with a web request. Later on, you decide to upgrade to the deluxe weather station, adding wind information. If you had a loose API that returns a collection of information in JSON or XML, consumers could continue to read the 'temperature' setting and ignore the new parameters they didn't recognize. However, if you used a more rigid protocol (like SOAP with WSDLs), the new data would need a new WSDL, and that means you either create a totally new interface (Query2()) as well as maintain the old interface (Query()) or you drop the old interface and require all the consumers to upgrade (sounds like a MS plot, doesn't it :) ? ) There are business cases for doing it both ways, depending on what you're doing, but the looser "send back a mess of data" is probably a better model for public services where you don't necessarily control, or are even aware of, the consumers of your service. Putting up new SOAP web services today is a disservice. It's worse than > laying out > your web pages using tables. It's a contract between producer and consumer. If both can live with the limitations of the contract between them (especially fixed components in a controlled environment), SOAP and EDI and other "legacy" formats have a place. -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cacw6n4sfnx68ee4kghke6zr8crhdy-nsgt9l9uqg4vsqt9p...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
