Hi Jan, I can only comment on (1) - my experience tells me that most tools/frameworks allow you to extract the entire query part as defined by the RFC (basically, characters between
? and either
# or the end of the URL) because it's really not a given that queries always follow the
key=value&... pattern. That also means you very likely have to parse the actual expression in the application, the same way you would if the expression were enclosed in a dedicated parameter (for the sake of an example, if it were
?s=quantity%3E5, you would still end up parsing the expression stored in s). I also guess that
== is used instead of
= to avoid any confusion between comparison and assignment.
------------------------------
Alexey Rusakov
Red Hat, Inc.
------------------------------
Original Message:
Sent: Mar 24, 2022 09:10
From: Jan Lemmermann
Subject: Confusion about comparison operator encoding
Hello Community,
When implementing Attribute Filtering in various TMF OpenAPIs, I noticed a few things when using the various comparison operators.
Chapter 4.4 of the TMF630 Guidelines Part 1 describes a number of operators.
1. one of the two variants for the use of operators provides the format <Key><UrlEncodedOperatorSymbol><Value>.
For example: /entity?quantity%3E5 for "quantity > 5".
If I interpret the RFC3986 correctly, such a string is allowed. It seems to me that some tools have a hard time with query parameters that do not match the key=value scheme.
Is there any experience from others here?
2. Looking at the "Operator literal" and "URL Encoded form" columns in chapter 4.4, I found a discrepancy.
The regex operator is described as *= which is converted to %2A%3D. But in the guide it says %3D~ which then corresponds to =~. Which variant is the correct one?
For equality: Is the operator == via %3D%3D necessary at all? After all, a consumer can also use key=value or should we still provide ==?
I would appreciate any hints and thank you in advance for your answers.
Regards,
Jan
------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH
------------------------------