----- Original Message ----- From: "Mark Baker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 02, 2002 14:15 Subject: Re: SOAP 1.2, GET, and Axis
> Hey Glen, > Did you get my reply[1] to Stuart, and Noah's "+1"? > > The method cannot be derived from the MEP. > > > I agree with Sam that there are still serious issues about how exactly you construct useful URLs which mean useful things, but that's another issue. > > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0016.html > I think I see what skw is getting at, but it confuses me. the model of REST is about state transfer; using GET, PUT, DELETE etc on state of objects at the far end. so I could have an object server/printqueue; PUT a new object in the queue, job17, and then set state on server/printqueue/job17, such as server/printqueue/job17/job-ticket=some JDF xml, then queue it for printingby setting its server/printqueue/submit=job17 but the SOAP ethos would be to call server/printjob::createJob, get back a ticket and then make some calls on that, before calling server//printqueue::submit(jobID) It is more procedural. Automatically turning something procedural into a state system is just wierd. Doing it by hand is ok, of course, but in that case Axis should really add PUT support, and be a lot better at dynamic creation of new endpoints. That is something it should add (.NET remoting does it nicely), but there is no rush. to put it differently, I think soap1.2 is good, but we dont have to rush into implementing all of the spec till the implementations are understood. Otherwise we will hard-code confusion into the world. -steve SOAP is about RPC/method calls, maybe async ones. if
