Section 7.6.2, Encoding of Information Resource Directory:
"Each entry MUST indicate a URI that either directly provides the
indicated Information Resource, or responds to a HTTP OPTIONS request
which provides an Information Resource Directory with entries of
additional Information Resources.
"If an ALTO Client makes a GET or POST request to a URI that does not
directly provide an indicated Information Resource, the ALTO Server
MUST either reply with an HTTP 300 status code ("Multiple Choices")
and an Information Resource Directory in the HTTP response¹s entity
body, or indicate an appropriate HTTP status code. Note that in
general, it is preferred that ALTO Clients use HTTP OPTIONS requests
to discover additional Information Resources."
Here's my philosophy about protocol designs: client-server protocols
should be designed to simplify the client. If that pushes work onto the
server, tough! The goal is to simplify the client.
So what's the problem with those paragraphs? Consider the first. That says
the server has two distinct choices. How can a client discover WHICH
choice the server made? "Try it and find out."
Please! That's an insult to client implementors. That's a clear case of
designing to simplify the server, at the expense of the client.
Furthermore, this means a client must use three techniques to get the
information from a info directory:
* A GET request to the primary directory URI,
* An OPTIONS request to a multiple-type URI, or
* A "300 Multiple Choices" error response to a GET or POST.
So what's my suggestion? Drop those two paragraphs completely. Instead,
allow the information resource directory to contain an entry for ANOTHER
resource directory, with additional services. The media-type would be
application/alto-directory+json, of course. Eg,
}, {
"uri" : "http://custom.alto.example.con/extra-dictionary",
"media-types" : [ "application/alto-directory+json" ]
}, {
Then if a client wants to explore those services, it can do a GET on that
URI.
And for those who think the original specification is necessary -- the
OPTIONS and 300 response and all that -- now that we've had a bake-off,
how many servers actually implemented those options? How many clients
supported them?
- Bill Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto