Re: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....

["Thomson, Martin" <[e-mail]>]

The idea that you propose - and your philosophy - violates one of the core tenets of RESTful design by increasing the coupling between client and server.

Stronger coupling is rarely good in the long run.  When you do that, you impose restrictions on both entities.  


Providing a robust resource discovery mechanism requires the sorts of mechanisms that are in the draft.

Avoiding trial and error is part of the reason that discovery exists.  However, that does not obviate the need for good error recovery. 


Your concern that a client is going to be forced to do more work than absolutely necessary is a little strange.  The directory provides enough information for a client to do what it needs to do.  

A basic client probably doesn't need to worry about 300 responses or OPTIONS for anything other than error recovery, providing that the server is sensibly structured and the directory is accurate.

The reason that we provide OPTIONS responses is that the directory cannot always provide _authoritative_ information about a particular resource, just a hint about it.  If the hint turns out to be wrong, then OPTIONS tells the client what the resource really provides.


That said...  The way the text is structured implies something more complicated than it needs to be.  That is, it implies that an entry MAY identify a resource in a way that is not sufficiently defined to actuate that resource.  That's bad.  It does the clients a disservice and ought not happen in anything other than an error condition.

Structuring the description in a different way could alleviate the problem.

1. a directory identifies resources as completely as possible
2. error handling requires good client feedback:
 (a) all resources provide responses to OPTIONS requests that identify their own capabilities
 (b) resources provide appropriate HTTP responses so that clients can correct mistakes (405, 406, etc...)

--Martin

On 2011-07-28 at 10:35:24, Bill Roome wrote:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto