Is using single or double quotes in query params to differentiate strings from numbers good API design?

Consider:

  1. GET /persons?firstName='Joe'&age=42
  2. GET /persons?firstName=Joe&age=42

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?

0 4 19K
4 REPLIES 4

Not applicable

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