Java REST API example?

Support
1

I am checking the examples at:
https://stardog.docs.apiary.io/#reference/core-api/executing-a-query/get

And I am wondering if there is a real example I can follow to call the API from Java (the Java example in the API documentation seems limited). I cannot find any in Github.

Specifically I am interested in how to translate the following to the REST API:
1- Set the reasoning in a query. In Java is done by query.reasoning(....);
2- Parametrize the query. In Java is done by query.parameter(.....);
3- Navigate over the results of a query. In Java is done by while (qResult.hasNext()) { ....

Thanks

2

  1. To enable reasoning you simply need to pass reasoning=true as a query parameter.

  2. You can include parameters on the query string e.g.,

/myDb/query?query=select * {?s ?p $foo}&reasoning=true&$foo='bar'
  1. The server can return results in a few different formats (SPARQL XML, SPARQL JSON, CSV, TSV), so it’s just a matter of parsing through that client-side
3

Thanks Stephen. But do you know if there is a real example out there I can have a look to? Especially to know how one or more of these formats are treated.

The problem with (2) as I understand you suggest is that it claims for an injection, whereas the original parameter() is, in theory, safe.

4

Sure, you can take a look at the W3C spec documents for the JSON, XML, and CSV/TSV SPARQL results standards.

As for the injection concerns, would the same concerns exist if you were to do a POST request with SSL over HTTPS with the query string parameters in the POST body?

5

Thanks Stephen.

Yes, the injection concerns remain. It doesn’t matter if the parameters are sent “securely”, the injection comes from user input, not from a man in the middle (which, by the way, could happened with POST+HTTPS too). It is a matter of input sanitation I think.

6

We do not perform string concatenation with parameterized queries, so if a user provides invalid values for the parameters the query will simply fail, it won’t run something arbitrary.

7

Mmm… But as I understood, this way you suggested allows things like this:

/myDb/query?query=select * {?a ex:b $foo}&reasoning=true&$foo=’?c . ?s ?p ?o .’

Or how is the $foo parameter supposed to be filled in? If there is no similar thing to “aQuery.parameter(…)” then it can be a victim of injection.

8

This would execute the query select * {?a ex:b "?c. ?s ?p ?o"}, which would return no results, unless that literal happened to be in the database.

No string concatenation means that the query is safeguarded such that what is being substituted for the parameters is always an IRI or a Literal, so it cannot alter the query.

9

Ah OK - I think I get it now. What you mean is that a similar “restriction/sanitation” applied by parameter() is done where the URL parameters are treated. So $foo can only be substituted by either an IRI or a literal. Thanks.

10

Sorry - One more question.

How the API distinguises if "foo" is a literal or an IRI? I ask this because I have Literals that goes like "http://www.." (f.ex. for the Website reference of an element) and if I place this in $foo it might be treated as an IRI instead.

11

A literal would be "http://example.com" and a IRI would be <http://example.com>

12

I know, but Stephen said that the substitution is not made directly from user input. So there should a process that distinguishes Literals and IRIs. Otherwise I could set foo as “<http://....> . ?s ?p ?o .”

13

We distinguish IRIs from Literals the same way they are distinguished in Turtle syntax. What you have here would not be parsed as a valid IRI, and therefore it would be a literal.

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.