Re: Service discovery redux - endpoint-based mechanisms

On 13 Aug 2009, at 03:38, Lee Feigenbaum wrote:

> (Eric or anyone else, please feel free to push for query-based  
> options, but I'm not including them in this message.
>
> Here are the proposed service discovery mechanisms that are based on  
> SPARQL endpoints. I've tried to include arguments for/against them  
> where I've picked them up in the discussion so far. Please augment/ 
> correct as necessary.
>
> Option 1 - HTTP-Header
>
> Any GET or HEAD request on an endpoint would use an HTTP response  
> header to provide a URL at which a service description for that  
> endpoint can be found. Argument for: The response of any query  
> issued against an endpoint will include a pointer to the service  
> description. Headers are easy to include and consume. Argument  
> against: This requires 2 requests to get the service description.

I've implemented this and it was OK, but felt a bit awkward. I prefer  
Conneg or OPTIONS I think.

> Option 2 - HTTP OPTIONS
>
> Return a service description in response to an HTTP request on the  
> endpoint that uses the HTTP OPTIONS verb. Argument for: Potentially  
> revives the underutilized OPTIONS verb in an appropriate way.  
> Argument against: OPTIONS is not commonly used and may be tough to  
> implement in certain environments (e.g. XHR?) Also, OPTIONS may not  
> have the proper cache semantics for service descriptions.

XHR is fine, I've tried it on Safari and FF, and seen enough mention  
of it on google to suggest that IE and Chrome support it.

The cache thing is a concern though.

> Option 7 - Conneg
>
> An HTTP GET request on a SPARQL endpoint without any query  
> parameters and specifying an RDF serialization in the Accept: header  
> would return a service description for the endpoint. (Suggested in http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Jul/0005.html 
>  .) Argument for: Allows for endpoints that today return HTML query  
> forms in response to a regular GET on the endpoint URI. Argument  
> against: May be an abuse of content negotiation to return something  
> which is not strictly an alternative representation of what would be  
> shown in the HTML version. Content negotiation is not always easy to  
> get right.

This seems the most web-friendly, on the face of it.

I share Alex's concern, but we have the opportunity to say "do it this  
way" in the spec. The main problem with conneg in general is that's  
there too much conflicting information on how to do it floating  
around, in my opinion.

> Option 8 - New protocol operation (?serviceDescription)
>
> A request to a URI such as /endpoint/sparql?serviceDescription  
> returns the service description. Argument for: Simple extension of  
> SPARQL protocol that maps nicely to non-HTTP instantiations of the  
> protocol. Easy to implement and invoke. A well-known pattern from  
> Web Services stacks. Argument against: ?? Not sure, other than Steve  
> is ok with it but not thrilled. :-)

There is an annoyance with it, which only just occurred to me. There's  
no really easy way to reference the actual endpoint with a relative  
URI, which is sadly necessary in many situations.

You can use </endpoint/sparql>, in the example above, but that won't  
work in the general case if the endpoint is being reverse proxied.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Thursday, 13 August 2009 20:23:10 UTC