Michael, > A reasonable design of an ALTO (client) implementation separates HTTP > processing from the ALTO protocol engine. The former is mostly a generic HTTP > instance (e.g., interfacing the well-known curl library), while the latter > realized the ALTO message parsing etc. In normal operation, both "layers" are > mostly independent. > > However, the RESTful design requires that ALTO error messages have to be > handled both in the HTTP layer as well as in the ALTO layer. Specifically, > the HTTP layer will have to decide based on the HTTP error code whether to > pass a response to the ALTO layer for further ALTO error message processing, > whether to do something else, or whether to consider the query as an entire > failure.
It could also use the presence of an app/alto-error (or whatever the media type is) message body & punt that to the ALTO layer. Without an ALTO specific error response in the message body HTTP doesn't give much room for providing rich error responses anyway, so the ALTO layer would be rather constrained with what it can do with just a HTTP status of 4xx or 5xx as there is unlikely to be a 1:1 mapping between ALTO errors and HTTP status codes. Ben > That distinction is much simpler if the implementor knows the HTTP error > codes that require further processing not only by the HTTP logic, but also by > the ALTO logic. > > Thus, for interoperability it seems indeed useful that the ALTO protocol spec > exactly defines the HTTP error codes for any ALTO error type (i.e., error > code 400 in spec -14). I don't see a good reason to change that - it would > make the HTTP logic in an ALTO implementation more complex and less > interoperable, because the implementor of a client has to guess what a server > might return. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
