Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URL query strings #10

Closed
SiBell opened this issue Jul 29, 2019 · 4 comments
Closed

URL query strings #10

SiBell opened this issue Jul 29, 2019 · 4 comments
Labels
clarification-required An element of the standard is ambiguous and needs more detail

Comments

@SiBell
Copy link
Contributor

SiBell commented Jul 29, 2019

Are we allowed to use query strings? If so are they any regulations we should be abiding by?

For example, let's say I want to request a list of all the deployments that are open to the public. Therefore my URL may look like this:

https://urbanobservatory.bham.ac.uk/deployments?public=true

Is this ok?

I remember hydra being mentioned, but I can't obviously see anything on there about this.

@SiBell SiBell added the clarification-required An element of the standard is ambiguous and needs more detail label Aug 1, 2019
@lukeshope
Copy link
Member

Hi Si,

Yeah this is an awkward one. Query parameters are absolutely allowed and encouraged. It would be great if Hydra could help us, but this part of the Hydra standard remains non-existent after five years.

The query parameters you do use though should be described, possibly by templated links.

There are some other standards or approaches people have adopted to filtering, that are able to accommodate more sophisticated filters than just exact matches. I think we need to look at a few and settle on one.

Other people have had the same issue. There's a good review here. Do you like the look of any of those approaches?

L

@SiBell
Copy link
Contributor Author

SiBell commented Aug 1, 2019

Templated links seem ok. Although I'm not entirely sure where I'd see this information. E.g. would it be included in the response from a request to https://urbanobservatory.bham.ac.uk/deployments? I.e. the response not only includes an array of deployments, but also details on how I can filter this list? I'm guessing we already have @context, @id, @type fields as in our example, so we just add another for this mappings, e.g. as in this example.

I'd probably veer towards the startDate__gt=2018-07-17T13:00:00Z approach. I prefer the look of startDate[gt]=2018-07-17T13:00:00Z, but square brackets aren't the safest of characters to have in a URL. I agree with the comments in that thread that the operators (gt, in, lte, etc) should be included before the equals sign.

@lukeshope
Copy link
Member

I think that's right, you simply extend your hydra:Collection with a hydra:search attribute containing the IriTemplate.

Happy to go with your suggestion of startDate__gt. I agree it should be part of the parameter name and not part of the value. We could specify both are acceptable, and implementations MUST accept the __gt form but MAY also accept [gt]?

I think the real fun begins when we start to consider spatial filtering on collections. Bounding box seems like an obvious MVP, but do we also need distance within a point for radial searches etc? How would that be expressed as an IriTemplate, and does Hydra offer the flexibility to define an IriTemplate that would work? Will have a think.

@lukeshope
Copy link
Member

Closing this as discussion on these matters is continuing in #18.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification-required An element of the standard is ambiguous and needs more detail
Projects
None yet
Development

No branches or pull requests

2 participants