Elaborate API requirement?

[jqnatividad]

What about adding more detail to the API requirement, in terms of:

• ability to filter queries, with true SQL syntax
• ability to subscribe to dataset/publisher activity streams
• ability to do joins
• ability to request for a list of datasets that have certain attributes (tag, metadata, publisher, etc.)

Also, beyond the Data API, having API access to other core Data Portal functionality, that could be leveraged by the publisher/administrator and third-parties to integrate the data portal into transaction workflows would be useful.

[technickle]

These are great suggestions.

One thing I am not sure about is "true SQL syntax". I think it is ambiguous. What variation of SQL? How does it get HTML-encoded? Is it passed\ as a query string or as a GET request header? etc. What if we made a more generic requirement which said that the API should approximate Structured Query Language, supporting at least all functions defined in SQL-92?

[jqnatividad]

For large datasets, having the ability to filter queries is essential - i.e. specify delta downloads so you don't need to download the entire dataset.

As for the syntax, having a "standard" query language is preferred. Explicitly specifying a subset of SQL-92 functions I think is a good requirement as it may not be reasonable to expect solution providers to support all SQL -92 features that may not apply to the Data API usecase.

SQL-92 features like joins, filtering predicates like "between", "like", "exists", "in", etc. should be included in the subset.

In addition, spatial filtering features would also be a big bonus! I'm afraid I'm not aware of a standard syntax for that, as it seems different datastore providers use their own syntax.