On 7/26/08, Michael Poulin <[EMAIL PROTECTED]> wrote: > > > > To Mark and Alexander: > why do you distinguish between REST and SOAP web services based on > external/internal usage of the service? To me, it does not matter while the > purpose of usage does matter.
For internal-facing services, tight coupling between client and server is often undesirable, but the cost is usually manageable because either the number of clients of a given service is low, or the clients are at least somewhat under your control (worst case - you share a common CEO) so you can mandate or at least coordinate changes. For public-facing services, most forms of tight coupling are a non-starter, because clients are, in general, parties that we have no prior relationship with. So, for example, we don't want to burden them with details of the implementation of our services (e.g. "we're changing the interface in 2 weeks, please update your software!"). Therefore, an architectural style for a public-facing service model requires architectural constraints which minimize coupling. REST has a bunch of them, while SOA has none that even a tiny chunk of the SOA community agree upon. Heck, there's *still* - nearly 10 years on now - no agreed upon definition of SOA in software architectural terms. Let's please try and keep this technical, i.e. in the language of software architecture. Thanks. Mark.
