-
Notifications
You must be signed in to change notification settings - Fork 2
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 with "structured" $filter in JSON body #1977
Open
ralfhandl opened this issue
Aug 23, 2024
· 5 comments
· May be fixed by oasis-tcs/odata-vocabularies#274
Open
/$query with "structured" $filter in JSON body #1977
ralfhandl opened this issue
Aug 23, 2024
· 5 comments
· May be fixed by oasis-tcs/odata-vocabularies#274
Labels
Comments
TC 2024-08-28: nice idea, let's flesh it out in a pull request and then decide whether we want to go that route. |
More detailed proposal see |
Also allow such structured system query options in action payloads? |
Query options cannot be passed in action payloads so far, do you want to open an issue for that? |
Let's wait until there is a requirement for that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#371 added JSON request bodies for requests to
/$query
where system query options can be passed as name-value pairs, restricting the system query option value to a string.This works fine for service implementations that have a full-fledged query option parser, and it is an implementation hurdle for less fortunate teams.
These would benefit from a "pre-parsed" JSON representation of system query option values, especially for
$filter
.Proposal
Allow CSDL JSON expressions as values for
$filter
.Define similar "pre-parsed" JSON representations for other system query options:
$compute
allows an object whose names are the dynamic properties to be computed and the values are CSDL JSON expressions$orderby
allows an array of one-property objects, each object having a property of eitherasc
ordesc
whose value is a CSDL JSON expression$select
allows an array of strings containing paths, nested query options are represented as an object of query options using these rules recursively that directly follows the path string it applies to$expand
similarly allows an array of strings containing paths, nested query options are represented as an object of query options using these rules recursively that directly follows the path string it applies toAllow this also for action/function parameters whose value is an expression:
"StartDate@expression":{...}
Add a Capabilities term to express which media types are supported for
/$query
, whether@expression
is supported, and whether the expressions can be stringy or JSONy.Example
Already allowed:
Allow additionally:
The text was updated successfully, but these errors were encountered: