- From: Steve Harris <steve.harris@garlik.com>
- Date: Sat, 12 Sep 2009 12:39:16 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 11 Sep 2009, at 15:13, Seaborne, Andy wrote: >> -----Original Message----- >> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg- >> request@w3.org] On Behalf Of Steve Harris >> Sent: 14 August 2009 16:58 >> To: Lee Feigenbaum >> Cc: public-rdf-dawg@w3.org Group >> Subject: Re: Service discovery redux - endpoint-based mechanisms >> >> On 14 Aug 2009, at 14:34, Lee Feigenbaum wrote: >> >>> Steve Harris wrote: >>> >>>>> 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, >>> >>> I'm feeling a bit dense today, but don't totally understand what >>> you're saying here. Mind giving an example? >> >> Sorry, the message was a bit terse. >> >> Imagine you have a SPARQL server running on >> http://localhost:8080/sparql/ >> , internally to a server, firewalled, and you want to reflect that >> externally as https://machine.example.com/myapp/sparql/ using a >> reverse proxy (this might sound a bit odd, but I know of at least >> three companies that are doing exactly this). >> >> If the service description if fetched from the exact endpoint URI, >> and >> the description looks like: >> >> <> a sparql:Endpoint ; >> sparql:has sparql:featureA ; >> ... >> >> Then it will all work fine, from both the native endpoint and via the >> proxy. >> >> However, if the description of http://localhost:8080/sparql/ lives at >> http://localhost:8080/sparql/?serviceDescription >> , then you can't use <>, so you have to write something like: >> >> </sparql> a sparql:Endpoint ; >> sparql:has sparql:featureA ; >> ... >> >> And that will give you an incorrect and unhelpful answer if you >> request it as >> https://machine.example.com/myapp/sparql/?serviceDescription >> >> - Steve > > Wouldn't <./> work for all cases where the service URL ends in "/"? Yes, good point, but that doesn't help if the URI doesn't end in a /. - 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 Saturday, 12 September 2009 11:39:53 UTC