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 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
Assignees
Labels
URL Conventions URL Conventions V4.03 Too vague or controversial for 4.02

Comments

@ralfhandl
Copy link
Contributor

ralfhandl commented Aug 23, 2024

#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 either asc or desc 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 to

Allow 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:

POST http://host/service/People/$query
Content-Type: application/json
 
{
  "$filter": "LastName eq 'P&G'",
  "$select": "FirstName,LastName"
}

Allow additionally:

POST http://host/service/People/$query
Content-Type: application/json
 
{
  "$filter": {
    "$Eq": [
      {
        "$Path": "LastName"
      },
      "P&G"
    ]
  },
  "$select": ["FirstName", "LastName"]
}
@ralfhandl ralfhandl added URL Conventions URL Conventions V4.02 labels Aug 23, 2024
@ralfhandl ralfhandl moved this to Open in OData TC Aug 23, 2024
@ralfhandl
Copy link
Contributor Author

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.

@ralfhandl
Copy link
Contributor Author

More detailed proposal see

@HeikoTheissen
Copy link
Contributor

Also allow such structured system query options in action payloads?

@ralfhandl
Copy link
Contributor Author

Query options cannot be passed in action payloads so far, do you want to open an issue for that?

@HeikoTheissen
Copy link
Contributor

Let's wait until there is a requirement for that.

@ralfhandl ralfhandl self-assigned this Sep 6, 2024
@ralfhandl ralfhandl added V4.03 Too vague or controversial for 4.02 and removed V4.02 labels Oct 23, 2024
@ralfhandl ralfhandl removed the status in OData TC Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
URL Conventions URL Conventions V4.03 Too vague or controversial for 4.02
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

2 participants