search

jackie1929 / linked-data-api

Automatically exported from code.google.com/p/linked-data-api
0 stars 0 forks source link

Interpretation of Unreserved Request Variables #9

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
http://code.google.com/p/linked-data-api/wiki/API_Binding_Variables says:
"All unreserved request parameters (ie those that do not begin with an 
underscore) are mapped directly into variable bindings"

http://code.google.com/p/linked-data-api/wiki/API_Selecting_Resources says:

"The set of parameter bindings from the api:filter should be combined with the 
unreserved request parameters. Where both sets contain the same parameter 
binding, the one from the request parameters should override the one from the 
api:filter."

suggesting that  unreserved request parameters should be treated as property 
chains, just like in api:filter ?
The usage in 
http://code.google.com/p/linked-data-api/wiki/API_Deployment_Example shows  
request parameters representing property chains.

The "Selecting Resources" page/section of the specification also says: 

"For each parameter binding, the name should be mapped to a list of properties 
[...]
It is an error if any of the parts cannot be mapped to a property. The API 
should return a 400 Bad Request error if the parameter binding came from a 
request parameter, and a 500 Internal Server Error if it was present in the 
configuration."

This means that if you try to specify a variable in request parameter, then the 
implementation will also try to interpret it as property path, and, if 
successful, use it to add conditions to the SPARQL SELECT, and if unsuccessful, 
will return a 400 Bad Request - the upshot of which is that you cannot specify 
variables as unreserved request parameters.

Original issue reported on code.google.com by K.J.W.Al...@gmail.com on 28 Jul 2010 at 7:51

GoogleCodeExporter commented 8 years ago 
[Duplicate of email response, hadn't realized these were on the issue tracker.]

My take is that the first section you quote is wrong.

The whole point of unreserved parameters is that they are property
paths, so that you can build up a query that way and later bake it into
the configuration. That's certainly how the original implementation
worked and the Edubase demo relied on it.

It we need arbitrary variable bindings in request parameters then I'd
actually reverse it and say that a request parameter "_foo=val", where
"foo" is not a reserved term for the API, should bind variable "foo" to
"val" where "val" is assumed to be a plain literal.

Original comment by Dave.e.R...@gmail.com on 16 Aug 2010 at 4:45