Three cheers for GET services

[Wil O'Mullane]

I shall be brief
> (1) Please find below an email that I sent to myself yesterday. It is a pointer
Pointed out many times and by Tony again. Making what you call a GET over SOAP
is very simple if the service is simple enough. In .NET if it is simple enough it does this for you automatically hence this is a SOAP service to the registry 

http://nvo.stsci.edu/voregistry/registry.asmx/QueryResource?predicate=servicetype%20like%20'%siap%'

I did nothing to produce this interface. 

More complex calls require POST but that is all.

> (2) On the same topic is the question of partial arguments to SOAP services. For
> example, under the GET system, I can *derive* a service from another. If service
> http://blah.edu/siap? returns images of all bandpasses, then the new service
> http://blah.edu/siap?BANDPASS=z can be derived (by simple concatenation!) that
> returns only z-images.
unsure what the point is here ..  you may also define SOAP interfaces to take 'extra' parameters but then it s not really the same interface any more better to call it something else. 

> 
> Or, for example, a client could go to a login screen at http://blah.edu/login
> and get in return email a URL containing his session number, such as
> http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this completes the login
> process.
Have you looked at CasJobs ?
http://casjobs.sdss.org/CasJobs/
all web services - seems to do exactly this ...

> 
> (3) There are a lot of nice read/parse qualities about GET requests. It would be
> nice to have both GET and SOAP at the same time. To somehow send keyword-value
> by the GET channel, but the complex objects and binary through the SOAP channel.
I do not know any nice READ/Parse qualities of what you call GET. Unless you mean every time i call you kind of GET I have to READ the response and PARSE out the information I wanted. On the other hand when I call a SOAP service I get back a meaningful object in my language - the reading and parsing are done by the library. 

> People know and trust the GET method. Crossing the bridge to SOAP should be
> possible by gradual steps.
see point 1.