Put this way, the argument would indeed be totally pointless. But what you have modeled is not *at all* what one would arrive at when designing a RESTful interface.
I've tried to elaborate using pictures here: http://www.innoq.com/blog/st/2006/06/30/ rest_vs_soap_oh_no_not_again.html Stefan 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. > > 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? > > As Steve says, this argument is really pretty pointless. > > 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 Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/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/
