Wondering if admin webUI -> new route -> Method(s) tooltip should be changed

[nitinthewiz]

Hi,

While creating a route in the Kong Admin web UI today, I realized that the Method(s) tooltip says the following -

"A list of HTTP methods that match this Route."

I traced this back to the admin-api autodoc here.

Now, for the API, this statement is correct. It is a "list of methods" in JSON.

However, the same is not true for the web UI. There, it should be described as "A comma separated list of HTTP methods..."

My first instinct was to send a PR. But thinking on it further, I can see that there's a slight disconnect caused by the same string being used in the API documentation as well as the Kong Manager web UI as a tooltip.

Looking for insight into what the resolution should be. As a newbie, it was pretty easy for me to guess that it would be a comma separated string of HTTP methods. But it can be clearer in the tooltip.

One resolution might be to have not just a description field in the autodoc, but also a "webui_description" field. If the webui_description is present, it should be used as the tooltip. In its absence, the UI should defer to the description field.

Thoughts?

[hanshuebner]

Hi @nitinthewiz,

I agree that "A list" is ambiguous when used in the Web interface, and it would be clearer if it read "A comma separated list" instead. Introducing a new autodoc field just for this instance of the issue sounds to me like being a relatively big hammer for a small ambiguity, however. Did you find any other instances where the wording is unclear? One could argue that instead of having users enter lists into a a text field, the methods should really be selectable with a multi-select dropdown.

Kind regards,
Hans

[nitinthewiz]

Hi @hanshuebner, I understand that it's overkill to add a whole new field for one instance.

Other places I've found this is in the same document on other "lists" like the hosts list - "A list of domain names", and paths - "A list of paths that match this Route." as well as snis, sources, and destinations. So it's more than one places where the ambiguity can be reduced. Though, it's worth considering that if real world users aren't seeing this as ambiguous, then it's not worth addressing with any urgency and can be tossed into the backlog.

Regarding the solution for list of methods - a multi-select would be the perfect replacement, giving users a clear choice of fixed options.