Parameter collisions don't err (but should?) #917
Labels
answered?
Waiting for confirmation that the issue is solved
docs
Related to documentation only
knowledge 🤯
Learn about common {plumber} problems
Issue created as a result of this Posit Community thread.
In spinning-up an API, I realized I had some lingering questions after reading the docs. One situation I was trying to understand is exactly how Plumber would handle scenarios where:
<x>
as part of a dynamic path,x
as a query string.x
as part of a parsed request body.In Routing & Input, there's this paragraph:
Here's a (very) simple endpoint definition:
The request will be a
GET
to/foo/bar?x=baz
with body{"x":"qux"}
.No error (the actual issue)
The response is not an error, but rather "baz" is returned, suggesting the query string takes precedence. I assume this is not necessarily the intended behavior but rather simply a byproduct of the order in which
req$args
is stitched together from theargsQuery
,argsPath
andargsBody
(which, BTW, is not the order mentioned in that doc paragraph) ... here'sreq$args
:A related issue/challenge?
In thinking about a safe way to deal with this, a potential related issue that comes up. I think(?) the most logical approach one would take to handle that scenario safely is something like:
@preempt queryString
to the annotations (to prevent "baz" from trumping "bar", above)@parser text
to force explicit handling of body data.The problem with those two steps is that
@preempt queryString
then also preempts the body parser. This is, of course, due to the ordereddefaultPlumberFilters
, but figuring this out requires a decent amount of reverse engineering & {plumber} source spelunking ... more than most R programmers are comfortable with, I think(?).There doesn't seem to be an easy way to deal with this dynamic path collision issue, save for:
(i) creating a new router and explicitly excluding
queryString
from the filters (i.e. not usingdefaultPlumberFilters
) then(ii) adding an explicit query string parsing step (i.e.
webutils::parse_query()
) to any endpoint expecting a query string.I believe this makes dynamic path parameters very challenging to use for any sort of public-facing API, as they're fragile and it takes sophistication beyond what's described in the docs for how to safely manage parameter name collision. Maybe I'm missing some additional docs on how to best do this without these additional steps (i, ii) mentioned above?
The text was updated successfully, but these errors were encountered: