API Gateway Path Parameters For Query Params?

[jthomas]

Is it possible for the API Gateway to support mandatory query parameters?

For example, the following URL structure.

 /name/{myname}/age/{myage}?id={id}

Path parameters support the structure for name and age parameters but user has also asked about enforcing mandatory query parameters.

[mhamann]

Query parameters are, by definition, not required. I have yet to come across a well-designed API that required query params.

In my opinion, this would be solving the problem in the wrong way.

Per your example, why not:

/{id}/name/{myname}/age/{myage}

[rabbah]

Per the URI RFC https://tools.ietf.org/html/rfc3986#section-3.4 query parameters contain non-hierarchical parameters.

Should the API GW enforce a style of API design that eschews query parameters?

Further if developers are migrating existing APIs which may not be well designed should they be excluded?

[csantanapr]

query parameters are usually used as optional information like filters and overrides.

Absolutely they can migrate not well designed APIs to OW nothing preventing them from using query parameters when they invoke their APIs

[rabbah]

Calling apis that use query parameters not well designed just confuses the issue --- which is whether the gateway should handle query parameters, in addition to path parameters. I can't tell from the comment @mhamann and @csantanapr if you're saying yes the gateway should understand query parameters, or no the gateway should be oblivious to them (and only understands path parameters).

[mhamann]

Path parameters are critical to the gateway routing the request, so there's not much choice there. Query params aren't as much, so it seems less important that the gateway be aware of them beyond ensuring they're passed through.

The gateway can use query params in a mapping context. That should already work.

The question here is whether or not the gateway should reject a request due to a missing query param rather than letting the backend handle it.

Rejecting a request due to a missing query param is technically different than what happens when a path param is missing (i.e. the latter generally results in a 404).

I'm not opposed to someone doing the work to add support for it. I believe Swagger allows the required: true property on any param. It's just not really on the gateway's "official" roadmap.