Consider:
Option 1 is more precise, but option 2 is common and the API just knows that age is a number.
So here's my dilemma with option 2:
I'm using BaaS as my backend to mock these "convenience searches" and I need to turn option 2 into a "ql=" query param request like:
GET /persons?ql=firstname = 'Joe' AND age = 42
Its easy if I use Option 1, but for option 2 my mock needs to know if "age" is a number in BaaS, but there's no easy way to know that. Therefore, I'm kind of coerced into using quotes and the consumer is required to specify the parameter as a string or a number:
GET /persons?firstName='Joe'&age=42
Again this is more precise but is it too much of an imposition for consumers and are there real world examples that use this approach?
I recently implemented an API that used option 1 and was happy with the result, if that helps. The usual admonitions about injection attacks apply here. Double quote is not a legal URL character and won't pass through most programming libraries and web intermediaries, but single quote is fine.
Thanks @Martin, is that a public API? I've not been able to find any APIs that use single quotes in query params.
Option 2 seems like the common solution, I'll just have to manage which params are numbers in my mock.
That API is not public yet — we're getting there. I agree option 2 is more common. I dislike having to hard-code special knowledge of property types where it is avoidable, which is why I prefer option 1, but I don't see any other objections to option 2.
To support embedded single quotes, BaaS requires a backslash (e.g. GET /persons?firstName='Joe'&lastName='De\'Something'&age=42
User | Count |
---|---|
7 | |
2 | |
2 | |
1 | |
1 |