Thanks Andy. Andy Seaborne wrote: > 1/ Service.java code could look in the Context for additional parameters > - but how might the code know which endpoints need which parameters? > (there may be several SERVICE calls to different places in one query - > don't want APi keys exposed to the wrong places!)
Indeed, parameters need to be kept and grouped by SERVICE endpoint. We can use a Map<String, Map<String,List<String>>> to map SERVICE endpoint URLs to a map of parameter-->values. Service.java can then get the Map from the Context and add the parameters to HttpQuery if there are any. If we do just 1/, OpService probably needs to change (to keep the parameters separate from the SERVICE endpoint URL). > 2/ Just not checking for "?" doesn't quite work (need to know there is a > "?" allowed and swap to "&") but API keys probably shouldn't be in > SERVICE URIs. Is there any other query string parameters that might > reasonably and sensibly be in the service URI? If it's just keys, then > (1) looks better. Or both. I can see how this could work and it can be general enough to leave all the parameters specified by users in their SERVICE <...> call. It needs to add query=... using either '?' or '&'. The specific use case I've seen did not any other query string parameter, however other SPARQL endpoints might have other additional (and/or optional) parameters. > What might a general design look like? We allow users to specify one or more query parameters when they use SERVICE <...?name=value>. We do 1/ keeping all SERVICE endpoint parameters separate from each others. > IIRC someone was looking to rework HttpQuery and see JENA-56. Ack. Time for a JIRA issue (i.e. improvement). Paolo > > Andy
