Anne Thomas Manes wrote: > Perhaps this example might help shead some light. > > Let's say you have a service that performs two different functions. > > In order to accomplish Function 1, the service requires certain input > information (Function1in) and it returns certain output information > (Function1out). Likewise, in order to accomplish Function 2, the service > requires certain input information (Function2in) and it returns certain > output information (Function2out). > > When using SOAP, your would define a single interface (portType) with > two operations: > - Function1 > - input Funtion1in > - output Function1out > - Function2 > - input Funtion2in > - output Function2out > > When using REST, you would define two resources: > - http://some-uri/Function1 > - http://some-uri/Function2 >
MB will correct me but I think functions are verbs, resources are nouns and from a REST perspective I focus on nouns not verbs. Thus you talk functions on an interface but I don't think you'll be talking functions in your REST equivalent. You'll be defining a set of resources against which you dispatch a simple, well-defined, fixed set of messages which will yield more resources. So I'm not sure your mapping's are right and thus I'm not sure your comparison is right either????? > If you POST Function1in to http://some-uri/Function1, you will receive > Function1out in response. You could also potentially encode the > information from Function1in into a query appended to the resource URL, > e.g, http://some-uri/Function1?foo=abc and use GET rather than POST. > > The advantage of using REST is that you can directly reference the > resource URI, and (as long as the resource is idempotent) you can cache > Function1out for later retrieval. The challenge I see with REST is > figuring out what the format of Function1in should be -- or even worse, > what the format of the query string appended to the URL should be. > > But otherwise, they are semantically equivalent. Either interface can be > used to access the service. > > So explain to me again why REST is such a paradigm shift? > It's not a paradigm shift but architecturally/design-wise it's _different_ - one is noun/resource oriented whilst the other is verb/function oriented. > As Steve says, this argument is really pretty pointless. > Not necessarily. One reason for arguments coming up over and over is because they haven't yet been resolved. We can agree to disagree, change our viewpoint or whatever. Argument is what produces change/progress and thus it's never pointless so long as we all have open/flexible minds. Lastly, resolution also potentially leads to clarity and heaven knows we could do with some of that. Dan. 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/
