In a RESTful system, a service has a *uniform* interface. When used in conjunction with HTTP, the operations are GET, PUT, POST, DELETE, and the semantics of those operations are defined by the HTTP protocol:
GET: return a representation of the resource PUT: replace the representation of the resource POST: add more information to the resource (and perhaps return a new representation) DELETE: remove the resource That does not mean that the signature must be "void OperationName(void)". In fact, the signatures should look something like this: representation resource.Get(); void resource.Put(representation); newRepresentation resource.Post(resourceInfo); void resource.Delete(); If you are doing truly RESTful systems, you don't have invocation parameters -- you simply have resources and resource representations. Many people use the POST method in HTTP to do unRESTful things -- like passing in a method request with parameters. That's how CGI works, as well as SOAP. But that defeats the core principles of REST -- you don't have custom methods. Anne On 9/1/06, Xinjun Chen <[EMAIL PROTECTED]> wrote:
Anne, Thank you very much! I really appreciate your responsive and insightful explanations, arguments, and pointers. I am also very excited to know the REST debate. Unique interface is my first impression of REST, like the HTTP protocol. Could I ask you another question on REST? Is it a must that in RESTful system, the service's operation must have a signature "void OperationName(void)"? Then how to transfer invocation specific parameters? Does it imply that we must turn to HTTP and put those operation parameters in HTTP attributes? Regards, Xinjun On 9/1/06, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > It's not a debate between POX and Axis (specifically) -- it's between > POX and SOAP/WS-*. And the REST debate is one between > service-orientation versus resource-orientation. Note that REST > doesn't preclude the use of SOAP and WS-*. The significant distinction > is in the operations exposed by the service. In unRESTful systems, the > service exposes a customized set of operations, e.g., getQuote, > getCustomerByID, calculateSalesTax, etc. In a RESTful system, the > service exposes a generic interface, e.g., Get, Put, Post, Delete. > Passing in a method name with a set of parameters is unRESTful. > > Here's a nice writeup on REST: > http://www.xfront.com/REST-Web-Services.html > > This article summarizes some of the debate about SOAP being too "enterprisey": > http://blogs.zdnet.com/service-oriented/?p=614 > > Also, you can Google "SOAP enterprisey" and find more. > > Anne > > On 8/31/06, Michael Larkin <[EMAIL PROTECTED]> wrote: > > Dear Anne, > > > > I would like to know more about the debate between AXIS and POX supporters > > and would be grateful if you would point me in the right direction (without > > bringing the debate into this forum). > > > > You said: "There is a growing backlash against the complexity of SOAP and > > WS-*, and in response, people are looking for a simpler, more native-Web > > approach to services. And that's POX -- Plain Old XML over HTTP. HTTP is a > > very powerful and scalable application protocol. It supports clean > > separation of header and application payload. It provides a means to support > > self-describing messages (using MIME types). It supports security (HTTPS) > > and stateful sessions (cookies). Many argue that the SOAP envelope and all > > the SOAP Headers are just a lot of extra clutter. And for many applications, > > that's true. POX is absolutely adequate." > > > > Thanks! > > > > Regards, > > > > Michael > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
