Peter Madziak wrote: > >>Nope, that is the INVOCATION mechanism > No. If you think this then I feel that you missed the key concepts > of REST. REST is an architectural style focused on the "transfer of > state" and NOT the invocation of operations (and it also presents a > uniform interface (GET,PUT,POST,DELETE) for transferring that state). > To think REST you have forget about invoking operations on a "business > service" and focus soley on transferring state between consumers and > providers. > > I am not sure if this is related or not, but I find that people have > no trouble with REST when they are talking about "services" providing > access to "nouns", i.e. what people like Pat Helland call > resource-oriented services (or Erl's entity-centric services) but do > have trouble when they try to translate that to "verbs", or what > others call activity-oriented (or task-centric for Erl) services. > > Consider this paper by James Snell > http://www-128.ibm.com/developerworks/webservices/library/ws-restvsoap/ in > which he puts forth the claim that REST aligns well with > resource-oriented services and WS-* aligns well with activity-oriented > services. What Snell missess, IMO, is that REST can align perfectly > well with activity-oriented services, it's just that when it does, the > resources become more verb or action based. For instance, in a RESTful > "car repair service" scenario, the consumer might be PUTing/POSTing > resources like "AutomotiveServiceRequest, or some such action-focused > beast.
This paper, I think, describes the problem well. REST is well-suited for applications that can express the state transfer using the simple web interface, but once you need more than that such as for activity-oriented services, something more is needed. REST doesn't provide any particular advantage in this later situation, just a different way of expressing the activity. An example for me would be to see a standardized way of doing workflow using the REST interface. I'm sure I could map the existing specifications into REST, but the result would be just as complex and no simpler to implement. The Microsoft article you cite discusses why it is important to think far beyond the concept of state-transfer. Dave Forslund > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
