Paul, On 11/24/06, Paul Fremantle <[EMAIL PROTECTED]> wrote: > It is perhaps a little bit wrong to talk about REST as an option for > a Service Oriented Architecture. Most existing services don't cleanly > map into REST, except those directly backed by a resource model such > as a database. Even a layer of stored procedures over the data is > likely to mean that you cannot map it into REST.
Not at all!! Resource oriented means little more than data oriented. Give me an example of something that you don't think maps well onto REST and I'll see what I can do. Don't get me wrong, there *are* scenarios which don't map well. Just not the ones you're suggesting, AFAICT. > I think its time to call the Rest-ians on their distinctions. There > are plenty of RESTians taking a hard line on what is "REST" and what > isn't, Because REST is *very* tightly defined. *cough* 8-) > and at the same time willing to say that REST is the only good > solution for an SOA. Whoa, nobody's saying that AFAIK. What we're trying to say at least, is that REST is a great place to start if your system is data oriented (large messages). More than anything though, we're trying to promote principled design; adopting architectural constraints which provide you the architectural properties you need for the context in which you'll be deploying your systems. By that measure, Web services are *not* principally designed; they're far too tightly coupled to be useful for integration at scale, or to evolve cleanly over time (which is, technically, a form of integration at scale). > Well, if you analyze most "services" and SOA they > aren't based on state transitions of resources. Trying to have your > cake and eat it? Sorry, I can't grok "based on state transitions of resources". Mark.
