I understand; I sometimes have that affect on people!
And yes, allowing a directory to identify other directories is
sub-optimal. But it's useful when the entity providing the resource
directory knows there's another server, but does not have the
authoritative answer for exactly what services that server provides.
Hence, "Sorry client, but ya better get the real information from this
guy."
Actually, here's my proposal in more detail. Each entry in the resource
directory would have one -- AND ONLY ONE! -- media type, and 0 or 1 accept
types. That's sufficient to define the service that entry provides and the
method it expects.
This does NOT mean that a URI is limited to one service, though, because a
uri can appear in several entries. For example, the following means that
"map-service" responds to a GET and returns the full map, or to a POST and
returns a filtered map:
}, {
"uri" : "http://foobar/map-service";,
"media-types" : [ "application/alto-networkmap+json" ]
}, {
"uri" : "http://foobar/map-service";,
"media-types" : [ "application/alto-networkmap+json" ]
"accepts" : [ "application/alto-networkmapfilter+json" ]
}, {
I'd also suggest that the resource directory MUST be authoritative (at
least within any Expires time). If the server cannot provide an
authoritative description of the detailed services, then it should have
give the uri of a directory server that can.
Given that, is OPTIONS still necessary?
- Bill Room
On 07/28/2011 13:19, "Thomson, Martin" <[email protected]>
wrote:
>On 2011-07-28 at 12:33:10, Bill Roome wrote:
>> I would appreciate it if you could explain how my proposal increases
>> the coupling between the client and the server.
>
>I apologise, your proposal did not increase coupling. 'twas the
>expression of philosophy that caused the allergic reaction.
>
>Thinking on it more, the technical proposal - that a directory can
>identify other directories - is perfectly fine. It's suboptimal, given
>that the first directory could just as easily include the second, but
>it's perfectly sound.
>
>There's a problem with resources that don't support GET, which is one of
>the cases where you get 300 responses and where you need OPTIONS
>requests. But the general guidance there is to avoid the creation of
>resources that don't do GET.
>
>--Martin
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
