Retrieving GET parameters - what am I doing wrong?

🚧 Developers
1

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.

mappings
{
	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:

{
"error":true,
"type":"AppException",
"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?

2

Try

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

3

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.

4

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).

5

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.