[TAP] draft 0.42 - errors

[Doug Tody]

On Wed, 29 Apr 2009, Paul Harrison wrote:

> I think that the signalling of errors as specified in section 2.7.4 in TAP is 
> rather perverse to say the least, as it does not follow normal HTTP 
> conventions (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). The 
> idea that a status 200 OK message should be returned when there is a TAP 
> error, means that it is much more difficult to write simple clients that can 
> make a decision about success or failure by examining a single return value - 
> i.e. the HTTP return status. The justification for always returning http 
> status 200 (OK) even in the case of an error seems to be that there is no 
> "error in the HTTP protocol" - however, the HTTP status values have various 
> classes, many of which indicate errors in what HTTP is transporting - e.g. 
> when you get a 404 response in your browser, it does not mean that HTTP has 
> "broken", but that that the page that you asked for does not exist - there is 
> an obvious analogy with TAP errors.

I have to disagree with this Paul.  As Pat points out, we want to
separate the logical service protocol (TAP) from the transport used
here (HTTP).  In part this is to permit other transports, such as SOAP,
or possibly even local area transports (e.g. a desktop message bus) if
we were to use such a service for data access within a single computer.

But the issue is more fundamental than that, as we also have to
consider application level APIs.  Applications (science applications,
not necessarily things like webapps) will often not see the HTTP
level protocol at all, rather they will use some high level API.
A HTTP-specific error code is meaningless at this level, rather we
want to know the nature of some service error, e.g., due to a service
operation failing in some way.  Pat notes that maybe we won't have
a SOAP interface anytime soon, but we will certainly have high level
application APIs almost immediately once TAP services are available.

HTTP errors are certainly possible and when they occur, indicate
an error in the HTTP transport, as you note above.  Logical errors
in either the service protocol or in the functioning of the service
cannot however be described adequately merely with HTTP error codes.
HTTP has nothing to do with what the service is actually doing.
For example if an invalid query is posed ("syntax error", "table
not recognized", etc.) HTTP can say nothing useful about that.
Hence we need to return an error response as part of the logical
service protocol, noting the specific service error which occurred.
A small VOTable is used for this.  Although the service operation
may have failed in such a case, the HTTP link worked fine and the
service is in fact functioning just fine.

Finally lets not forget that all the current DAL services already work
this way, and we want to end up with a consistent set of DAL services.
The way proposed for handling TAP service errors is the same as in SSA
(as well as the legacy services), and is part of the DAL2 architecture
and standard service interface adopted with SSA.  This was based upon
OpenGIS standards, which also work this way.

 	- Doug