Three cheers for GET services

[Guy Rixon]

Roy,

things that HTTP-Get can do that SOAP can't:

 - express a request in a _compact_ string;

 - be invoked from an ordinary web-browser or similar HTTP agent.

AFAIK that's all.

The compact-string thing is important if you want to sent a request in hte
body of an email. You _can_ send a canned SOAP request to a colleague: it's
just an XML document. It's probably a big document, so you might want put it
in an attachment. You can put the address of the target service into the SOAP
header using WS-Addressing. You'd need a client to send the message: maybe a
web page. Should we write one?

Things SOAP can do that HTTP-get can't:

 - send long lists of parameters (there's a limit on hte length of the
   URL in HTTP-get)

 - send structured parameters (HTTP-get only does scalars)

 - send parameters controlled by a W3C XML schema

 - protect the request parameters via digital signature (HTTP-get
   messages can be intercepted and altered)

 - send self-authenticating messages without pre-agreed passwords

 - send messages through an intermediary, e.g. to get past a firewall
   (possible but messy in HTTP-get; built in with SOAP)

 - send the same message format via many protocols, e.g. HTTP, SMTP, JMS

Note that you _can_ describe HTTP-get services in WSDL; W3C has defined
bindings for HTTP-get and HTTP-post. However, we don't have any tools that do
anything useful with these descriptions (unless .NET has something: Wil?).

I agree with Tony that SOAP is for machine-to-machine communications. If we
want machine-to-human communications then we have to write a UI, which can
itself be a HTTP-get service.

Cheers,
Guy


Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523