Retrieving GET parameters - what am I doing wrong?

I've used the sample provided by bertabcd1234 in this thread to create an app that exposes a local endpoint I can call.

I got that working fine, and then used the answer provided by JustinL in this thread to try and access a parameter added to the URL.

	path("/myFirstMapping") {action: [ GET: "myHTMLEndpoint"] }
    path("/dashboard/:controllerID") { action: [ GET: "buildDashboard"] }

def buildDashboard()
    def controllerID = params.controllerID
    log.debug("buildDashboard() called, controllerID is $controllerID")
    render(contentType: "text/html", data: "Text on the page")

shows the extent of my changes: the extra mapping, and the addition of the buildDashboard() function

I then made a call to http://<my hubitat address>/apps/api/212/dashboard?access_token=<correct access token>&controllerID=XYZ1234 but that resulted in an error: my copy of buildDashboard() is never called, and the endpoint returns the following JSON error:

"message":"Not Found"

Note that 212 is the correct App ID since that works for the original endpoint.

Any ideas what I'm doing wrong?


http://<my hubitat address>/apps/api/212/dashboard/XYZ1234?access_token=<correct access token>

Not what I would have expected, but that does work. This probably means a change of plan: I was expecting to send a short JSON blob as the parameter, but I don't see that working well as part of the URL. I'll need to determine how to get the payload of a POST request.

Do you have a particular need to use GET? If not (and if you still want JSON), you could put it in the body parameters for a PUT or POST. You could probably URL-encode it and use it in the GET, too, but I'm not a huge fan of how messy that can make things (and probably wouldn't risk it with anything that could be long).

I'm definitely not required to use GET, and judging by what I know now, I agree that's probably not the best tool for the job. URL encoding it as a parameter after the question mark would have been possible, albeit a little messy at times. Sending it as a component of the URL on the left of the question mark seems like there's a bit too much that could go wrong.

Sending the JSON as the body of a POST request would definitely be my best bet now, since I have complete control over the system that will be sending them, it's not a major problem. I'd just need to tweak the "micro http" client I'm using to send the payload as the body of the POST request.

Then I just need to determine how to get the body in the function that actually fields the request, and I'm home free.