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

Query string values that mean "not set yet". #15

Closed
SiBell opened this issue Aug 30, 2019 · 5 comments
Closed

Query string values that mean "not set yet". #15

SiBell opened this issue Aug 30, 2019 · 5 comments
Labels
clarification-required An element of the standard is ambiguous and needs more detail

Comments

@SiBell
Copy link
Contributor

SiBell commented Aug 30, 2019

Example

Let's say I want to get a list of all my sensors:

GET /sensors

If I want to get all the sensors in a given deployment then I could use:

GET /sensors?inDeployment=public-weather-stations

Now what if I want to get all the sensors that are not in a deployment yet?

Possible solutions:

  1. GET /sensors?inDeployment=false

Downside: You'll have to ban deployments called 'false'. The same would apply if you used null instead of false.

  1. GET /sensors?inDeployment=

Downside: This is ambiguous as to whether it means a) give me all sensors whatever the deployment, or b) gives me sensors not in a deployment.

  1. GET /sensors?assignedToDeployment=false

Downside: You need to document another query string parameter. And probably forbid the presence of inDeployment when assignedToDeployment=false.

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

lukeshope commented Sep 4, 2019

Could we adopt the same approach proposed for greater than/less than cases?

Something along the lines of inDeployment__isNull=true or inDeployment[isNull]=true?

@SiBell
Copy link
Contributor Author

SiBell commented Sep 4, 2019

Works for me.

I'd planned not to include any Null values in my API response, i.e. this:

{
  "id": "sensor-1",
  "name": "sensor 1"
}

Rather than this:

{
  "id": "sensor-1",
  "name": "sensor 1",
  "inDeployment": null
}

Assuming it's fine to omit null properties, and doesn't break any rules of the standards we're sticking to, then perhaps inDeployment__isDefined=false is better?

@lukeshope
Copy link
Member

Happy to go with isDefined as a the condition, I agree about not including nulls in these cases. Should we come up with a list of all the conditions we think we might need to use as query parameters, and the types they're applicable to, as in

  • isDefined can be used for IRI references
  • gte, lte, gt, lt for numeric values
  • contains, overlaps, withinDistance or similar for spatial conditions
  • straight forward equals for booleans, strings, etc.
  • wildcard or regex matches for strings?

@SiBell
Copy link
Contributor Author

SiBell commented Sep 5, 2019

Yep good plan. Pop them in a table and whack it in the standards draft, e.g:

conditional properties types applicable to description example
gte numbers, date strings Filter resources by property values greater than or equal to that specified startdate__gte=2019-05-24

What me to make a first stab at this?

@lukeshope
Copy link
Member

Closing this as discussion of the same matter has now moved to #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