Consideration to improve "Request Mappings" for Spring Boot Actuator to request data for URL/URI execution

Hello Team

For a Spring Boot project working with Web and Actuator

Observe the following Figure

If I do double click in the /ciencias/uri/ciencias URI selected (The one located in the Path header) then is opened the internal web browser and works, it because the URI does not work with:

• netiher a parameter nor path variable

Now consider the following URI

As you can see the /ciencias/uri/ciencias/{id} URI works with the {id} path variable. So when is applied double click then the internal web browser is opened as expected but shows the following error:

Of course it has sense because the {id} path variable never was defined.

Therefore: Could you pls consider in improve by adding the following feature?:

• If the IDE detects at least a path variable then when is accomplished the double click a small dialog window should appear with a text field to put the path variables separated by commas

It such as the same approach to work with varargs such as a Object....

Consider the same request if the handler method works with at least one Request Parameter

The point is that there is flexibility.

It would be applied for DELETE where is need it normally a {id} too. Now for POST and PUT the Dialog Window through the unique text field should let put the content data as either json or xml format. Something similar as cURL

• Does it have sense to you?
• Or Did I do understand incorrectly the purpose of Request Mappings?

So far I think it has sense, but would be problematic for:

• HTML for POST and even being viable for DELETE and PUT too because is used the HiddenHttpMethodFilter class - How to send the data?
• HTML or REST working with either paging and sorting (even both together) - How to send these extra parameters?

Let me know your thoughts

No source files, tests, or entry points are identified in the issue. Start by locating the Request Mappings and Spring Boot Actuator request-execution UI, then review how parameterized paths, request parameters, methods, and bodies are currently handled. Done should include an agreed scope and behavior for interactive requests with missing path or query values and request bodies.