On Tue, 31 Oct 2006, Kona Andrews wrote:
>
My take on this is as follows.
The suggestion made in the meeting (by Pedro originally I think) was that the REST interface, due to its simplicity, should be mandatory, and the SOAP interface and advanced capability (probably a "should" provide for a fully compliant service). A fully compliant service would provide both interfaces simultaneously to a given service instance. The SOAP interface would probably be required to access the more advanced capabilities of the service, e.g., to support authentication.
The argument made against this was that capabilities such as authentication may be required to access certain data at all, e.g., proprietary data from a telescope observing run. It was argued that there would be little point in providing a REST interface for proprietary data since one couldn't access the data via this protocol.
If this is true however for catalogs, then it is even more the case for image data (for example), since proprietary data from a telescope observing run more likely to be a collection of images than a catalog, as the latter is an advanced, derived data product. Usually by the time someone generates a catalog it is near the end of their research project and they want to publish it in any case.
Hence if we buy this argument about proprietary data, it is even more valid for SIA than for TAP. But clearly SIA has been very successful in accessing public data. The REST interface is adequate for most SIA usage, and SOAP is probably only required to support grid capabilities such as authentication and asychronous data staging - just as for TAP. I suspect that most catalog data in the VO is public and the same arguments will hold for TAP as well.
Furthermore, if we look at the service interface for TAP it will probably have a number of operations such as the following:
query data
query metadata (various, TBD)
stageData (async operations, TBD)
getCapabilities
state-of-health
Even for proprietary data, getCapabilities and state-of-health should function. Querying the database/catalog metadata will probably also be permissible even for proprietary data. The data query would probably fail, reporting an authentication error. The grid stuff (stageData) we are already assuming is an advanced capability which simple services would not offer, and may be available only via SOAP.
Hence, even for a REST interface accsesing proprietary data, most of the interface should work. A data query would return an error indicating insufficient authorization, but that is useful information in its own right, and the interface would still function.
Frankly my biggest motivation for suggesting that providing a REST interface be mandatory is that if we don't do this, different service instances will implement one or the other interface randomly, and this will be harder than necessary for client software to sort out. If a service implements only a SOAP interface, simple queries will not be possible for clients that do not support SOAP, even though the data itself may be public. If a service implementation supports a SOAP interface it is pretty easy to support a simple REST interface as well; why not just do so? We should also continue to support simple parameter-based interfaces such as the simple cone search, for data such as a source catalog where this makes sense.