You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 3, 2019. It is now read-only.
Breaking the path into resources and predicates would be helpful too when processing the OData URL, because hre can be expressions inside the path. For example, /Customers(123)/ContactName could be parsed into a JSON object with a schema similar to the query parsing output:
There could be either a separate parsing function for the path, or the current odata-parser module could support both; the path with an optional query or the query alone.
I could not find a real advantage of having handling the two URL parts separated. A disadvantage was duplicating a big part of the PEG grammar in the URL path handling file. Parsing can handle all three possibilities (path, path + query, query) with a simpler interface (just a single parse method) and the only challenge is how to return the path without breaking the current interface. I tried adding a new key - $path - to the output map in the parse-path-integrated branch; it is not a reserved OData field and the parse method has a common result schema:
{
"$path": [
// array of resources from the first and second samples above
],
"$select": [
"Name"
],
...
}
What do you think? Thanks!
The text was updated successfully, but these errors were encountered:
Breaking the path into resources and predicates would be helpful too when processing the OData URL, because hre can be expressions inside the path. For example,
/Customers(123)/ContactName
could be parsed into a JSON object with a schema similar to the query parsing output:Another example for
/Orders(CustomerID=123,Pending=true)
could be:There could be either a separate parsing function for the path, or the current
odata-parser
module could support both; the path with an optional query or the query alone.I tried the former in the parse-path-separate branch with the extended interface in
lib/index.js
:I could not find a real advantage of having handling the two URL parts separated. A disadvantage was duplicating a big part of the PEG grammar in the URL path handling file. Parsing can handle all three possibilities (path, path + query, query) with a simpler interface (just a single parse method) and the only challenge is how to return the path without breaking the current interface. I tried adding a new key -
$path
- to the output map in the parse-path-integrated branch; it is not a reserved OData field and the parse method has a common result schema:What do you think? Thanks!
The text was updated successfully, but these errors were encountered: