Anne, On Jun 30, 2006, at 2:33 AM, 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 > > 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. > This completely misses the point (sorry). With REST you'd ned to approach your use cases in terms of transferring resource state. Can you provide a real world example for the abstract case above? I'd then be able to provide the RESTful approach. > 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? Because it leads to a fundamentally different design of the overall system (by way of the constraints it imposes on the architecture). That in trun (among other things) leads to a system that is optimized for the networked-system case (IOW, using REST in a single process systen, say a word processor, is pretty pointless) > > As Steve says, this argument is really pretty pointless. Once you see the paradigm shift you'll see that the argument is one of different system properties imposed by diffeerent architectural styles. Jan > > Anne > > > On 6/29/06, patrickdlogan <[EMAIL PROTECTED]> wrote: > > > [SJ] An interface defines the FUNCTION as well as the data. Data > > exchange is only one small part of a service definition. Some > > functions never exchange any data for instance. I might be very > > thick, but when I define a service interface I think in terms of the > > capabilities that it provides, these don't often get reduced to just > > resources and data. > > In SOAP/WSDL you have the mechanisms to define the interface to any > functions you desire. Your architecture can be a hodge-podge. > > In HTTP you *should* use the pre-defined methods to transfer data here > and there. Your architecture can be a hodge-podge, but at least not > because you have a zillion and two interfaces. > > Think of the HTTP "functions" along the same lines as the > Linda/Javaspaces "functions". There are just a very small number of > them, and all they do is move things from here to there in a small > number of ways. With these two architectures, you have to understand > the best ways to use them. > > With SOAP/WSDL, you have to understand how to define an interface. But > then you also have to understand what your architectural choices are, > and how to implement that. HTTP takes a good bit of that burden off of > you. > > > > [SJ] But is REST that much better than WSDL? I'm not seeing it > > SOAP/WSDL is not an architecture. It is an interface definition > language with which you can define all kinds of architectures. Just > choosing WSDL doesn't solve the architecture question. > > REST is an architecture "pattern" if you will. HTTP is an incarnation > of REST. I don't see any way to compare HTTP and SOAP/WSDL. I think > you have to compare HTTP in whole or in part to some other > architecture that you may base in whole or in part on SOAP/WSDL. What > is that other architecture for you? > > -Patrick > > > > > 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/
