Subject: Re: Web Service 'IPersist' Interface? - msg#00049

Previous Message by Date: click to view message preview

Re: Web Service 'IPersist' Interface?

Thanks for the reply. Had a think about that and come up with this - Is there any merit in the arguement that there should be a 'XSD based spec' for these types of operations rather than HTTP/1.1 methods? This would: (1) Help people discover that these type of operations would be supported through WSDL. (2) Evolve in a controlled manner (its a schema and we're all carefully ignoring version issues for 1.0 land <g>). (3) Be consistent with my other SOAP method calls on the service (important one for me). (4) Be *so* much more fashionable to today's young people than HTTP1.1 <bg> Thanks, David You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other DevelopMentor lists at http://discuss.develop.com.

Next Message by Date: click to view message preview

Re: Web Service 'IPersist' Interface?

Did some more thinking, re-read the SOAP 1.2 draft (esp. the Adjuncts) and I *do* see what you mean. It's still not quite comfortable in my mind that I'm using the SOAP HTTP bindings for DELETE, but I like the fact that they're ubiquitous (which is the point, right?). I'm straddling Doc-msg style and RPC style, I guess, because the 'Delete', 'DoWork' etc calls are not 'safe and idempotent' methods. I feel inconsistent because sometimes I identify the resource via URI and other times not. This must come up a lot and it would have been nice if 1.2 had specified beyond GET/POST (esp. faults). I also want to re-evaluate what we've produced already to be more in the spirit of a 'web-architecture compatible way' (although not today :)) Thank you for your help, David On Tue, 20 Aug 2002 16:46:29 -0400, Noah Mendelsohn <noah_mendelsohn@xxxxxxxxxx> wrote: >In case it's not 100% clear, Mark is proposing that you use HTTP's methods >(GET/PUT/POST/DELETE). Note that the SOAP 1.2 Last Call draft has support >for such methods, though only POST and GET are directly encouraged for >interoperable use at this time. (Nothing prevents you from building a SOAP >server that deletes SOAP resources in response to a DELETE, however. It's >a cool thing to do; it's just that the SOAP bindings do not currently >specify and SOAP faults or processing for DELETE, as they do for POST and >GET.) > >------------------------------------------------------------------ >Noah Mendelsohn Voice: 1-617-693-4036 >IBM Corporation Fax: 1-617-693-8676 >One Rogers Street >Cambridge, MA 02142 >------------------------------------------------------------------ > > > > > > > Mark Baker > <distobj@xxxxxxx> To: SOAP@xxxxxxxxxxxxxxxxxxx > Sent by: cc: (bcc: Noah Mendelsohn/Cambridge/IBM) > Discussion of Subject: Re: [SOAP] Web Service 'IPersist' Interface? > implementing SOAP > applications > today > <SOAP@xxxxxxxxxxx > ELOP.COM> > > > 08/20/2002 04:22 > PM > Please respond to > Discussion of > implementing SOAP > applications > today > > > > > > >On Tue, Aug 20, 2002 at 12:18:10PM -0700, David Ing wrote: >> If this was 5 years ago I would be reaching for 'IPeristStreamInit' with >> its Load/Save. I know that HTTP intrinsically has its GET/POST verbs but >> we're looking for slightly more, i.e. Create, Load, Save, Update, Remove, >> List, y'know the usual suspects. > >You can do those with GET/PUT/POST/DELETE, I believe. > >"Create" can be done in one of two ways; if the agent doing the creating >knows the URI, then you can use PUT. If it doesn't know the URI, and >wants the server to return one, it can POST the data to some container >and then will receive a 201 response with the URI indicated in the >Location header. > >"Load" is probably just GET. > >"Save" would be PUT, since presumably you know the URI of what it is >you're saving - otherwise use POST as above. > >"Update" - is this different than save? > >"Remove" would be DELETE. > >MB >-- >Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) >Ottawa, Ontario, CANADA. distobj@xxxxxxx >http://www.markbaker.ca http://www.idokorro.com > >You can read messages from the SOAP archive, unsubscribe from SOAP, or >subscribe to other >DevelopMentor lists at http://discuss.develop.com. > >You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other >DevelopMentor lists at http://discuss.develop.com. You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other DevelopMentor lists at http://discuss.develop.com.

Previous Message by Thread: click to view message preview

Re: Web Service 'IPersist' Interface?

On Tue, Aug 20, 2002 at 02:38:35PM -0700, David Ing wrote: > Thanks for the reply. Had a think about that and come up with this - > > Is there any merit in the arguement that there should be a 'XSD based spec' > for these types of operations rather than HTTP/1.1 methods? This would: I'm not sure what you mean by "XSD based spec", so it's hard to say. You mean XML Schema datatypes, I assume? How would those replace HTTP methods? > (1) Help people discover that these type of operations would be supported > through WSDL. Sure, you could specify HTTP methods or equivalents in WSDL. I guess the question would be, why? 8-) WSDL is a design-time artifact, whereas you know that a resource is an HTTP resource at runtime, by looking at the URI scheme. e.g. if you see http://www.yahoo.com, you know that you can use HTTP methods, or if you see ftp://example.org/foo.zip, you know that you can use FTP methods. Very different than with WSDL, where you have to know the type of the service *before* you invoke the methods. It's a much earlier form of binding than the Web uses. > (2) Evolve in a controlled manner (its a schema and we're all carefully > ignoring version issues for 1.0 land <g>). I'd need to understand your XSD comment above to answer this one. > (3) Be consistent with my other SOAP method calls on the service (important > one for me). I guess this relates to the comment in your other message, about having trouble reconciling the document-centric use of HTTP and its methods, with the RPC use of SOAP. It *should* be difficult to do this, because the two approaches are mostly at odds with one another, especially when the common use of SOAP, and the libraries that support this use, eschews the use of URIs. > (4) Be *so* much more fashionable to today's young people than HTTP1.1 <bg> LOL 8-) BTW, I should state a disclaimer; I think that Web services are a huge waste of time, and that they completely disregard pretty much all of the important contributions that the Web has made to the design of large scale distributed systems. So hearing me espouse the value of using HTTP's methods (and extension methods) shouldn't be too surprising; I'm like a broken record in that way. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@xxxxxxx http://www.markbaker.ca http://www.idokorro.com You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other DevelopMentor lists at http://discuss.develop.com.

Next Message by Thread: click to view message preview

Re: Web Service 'IPersist' Interface?

Did some more thinking, re-read the SOAP 1.2 draft (esp. the Adjuncts) and I *do* see what you mean. It's still not quite comfortable in my mind that I'm using the SOAP HTTP bindings for DELETE, but I like the fact that they're ubiquitous (which is the point, right?). I'm straddling Doc-msg style and RPC style, I guess, because the 'Delete', 'DoWork' etc calls are not 'safe and idempotent' methods. I feel inconsistent because sometimes I identify the resource via URI and other times not. This must come up a lot and it would have been nice if 1.2 had specified beyond GET/POST (esp. faults). I also want to re-evaluate what we've produced already to be more in the spirit of a 'web-architecture compatible way' (although not today :)) Thank you for your help, David On Tue, 20 Aug 2002 16:46:29 -0400, Noah Mendelsohn <noah_mendelsohn@xxxxxxxxxx> wrote: >In case it's not 100% clear, Mark is proposing that you use HTTP's methods >(GET/PUT/POST/DELETE). Note that the SOAP 1.2 Last Call draft has support >for such methods, though only POST and GET are directly encouraged for >interoperable use at this time. (Nothing prevents you from building a SOAP >server that deletes SOAP resources in response to a DELETE, however. It's >a cool thing to do; it's just that the SOAP bindings do not currently >specify and SOAP faults or processing for DELETE, as they do for POST and >GET.) > >------------------------------------------------------------------ >Noah Mendelsohn Voice: 1-617-693-4036 >IBM Corporation Fax: 1-617-693-8676 >One Rogers Street >Cambridge, MA 02142 >------------------------------------------------------------------ > > > > > > > Mark Baker > <distobj@xxxxxxx> To: SOAP@xxxxxxxxxxxxxxxxxxx > Sent by: cc: (bcc: Noah Mendelsohn/Cambridge/IBM) > Discussion of Subject: Re: [SOAP] Web Service 'IPersist' Interface? > implementing SOAP > applications > today > <SOAP@xxxxxxxxxxx > ELOP.COM> > > > 08/20/2002 04:22 > PM > Please respond to > Discussion of > implementing SOAP > applications > today > > > > > > >On Tue, Aug 20, 2002 at 12:18:10PM -0700, David Ing wrote: >> If this was 5 years ago I would be reaching for 'IPeristStreamInit' with >> its Load/Save. I know that HTTP intrinsically has its GET/POST verbs but >> we're looking for slightly more, i.e. Create, Load, Save, Update, Remove, >> List, y'know the usual suspects. > >You can do those with GET/PUT/POST/DELETE, I believe. > >"Create" can be done in one of two ways; if the agent doing the creating >knows the URI, then you can use PUT. If it doesn't know the URI, and >wants the server to return one, it can POST the data to some container >and then will receive a 201 response with the URI indicated in the >Location header. > >"Load" is probably just GET. > >"Save" would be PUT, since presumably you know the URI of what it is >you're saving - otherwise use POST as above. > >"Update" - is this different than save? > >"Remove" would be DELETE. > >MB >-- >Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) >Ottawa, Ontario, CANADA. distobj@xxxxxxx >http://www.markbaker.ca http://www.idokorro.com > >You can read messages from the SOAP archive, unsubscribe from SOAP, or >subscribe to other >DevelopMentor lists at http://discuss.develop.com. > >You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other >DevelopMentor lists at http://discuss.develop.com. You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other DevelopMentor lists at http://discuss.develop.com.