It sounds like your view of REST comes down to "use GET whenever you can". There's nothing wrong with that, and it does indeed offer the advantage that a browser can be used to view the result. It doesn't seem to have much to do with Roy Fielding's thesis, though, which most people seem to regard as the foundation of the REST approach. Hmmm... do we need to rename this thread to "GOA is not ROA"? :-)
For simple Web services, exposing a method call as a bunch of parameters passed via GET does make it easy for all types of clients to access the service. But this is just another form of RPC, and I see it as very limiting when you're building complex systems. Sending XML in both directions (whether wrapped in SOAP or not) is a little more complex, and may give some types of clients problems - but it offers a lot more flexibility and room for future expansion. - Dennis Mark Baker wrote: > Thank for having such an in-depth look at the issue, Dennis, but I > could have saved you some time; you're making inferences about the > intent of Amazon's software based on how the URIs look, and while you > may very well be right, it doesn't matter because it's irrelevant to > the architecture; GET returns the data whether there's query > parameters, operation names, misuse of hierarchy, or whatever good or > bad practice you might care to name. > > There's one comment you made that I wanted to respond to though ... > > On 11/25/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > >> The only RESTful part of the GET-based XML interface seems to >> be that it *does* use "GET" rather than "POST" - but I can't see any >> advantage provided by this, aside from making it easier for users to >> generate requests as text strings (which is not one of the claimed >> benefits of REST, AFAIK). >> > > There are many advantages depending upon what angle you're looking at > it from - caching, security, reliability, etc.. In general though, I > think the big one is that any HTTP client anywhere can turn that URI > into data using GET. If POST were used, then clients would also have > to know *what* to POST, removing that benefit. Coordination costs are > less (effectively zero) using GET. > > Mark. > > > > Yahoo! Groups Links > > > > >
