On 11/27/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > It sounds like your view of REST comes down to "use GET whenever you > can".
Well, whenever you're requesting data from some other party, sure; that's what GET is for. If you're sending them data though, GET's not suitable. > 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"? :-) Rest assured that, to the best of my ability, all of my arguments are firmly grounded in Roy's dissertation. > 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, It's not. If a server publishes a URI that includes the string "getFoo", and somebody stumbles upon that URI and passes it to curl (or wget, or their browser bar, or ...), they are not invoking the getFoo operation as would be the case with RPC. No, the architecture is significantly different; by wrapping the operation in the URI, they've hidden it from clients, and the operation thats invoked across the network is GET, not getFoo. getFoo might still be invoked by the server on its own objects, but it's not part of the *contract* that exists between that person's browser and the publisher's server. Mark.
