URI Variables in CoAP are not supported

[egekorkan]

Smart coffee machine Thing produces CoAP forms even if there are uri variables for that affordance. But there is no support for that in CoAP so those forms are not usable at all. Either the support for URI variables should be implemented or forms should not be generated for coap in that case.

[relu91]

Are we talking about the server side or the client side? Giving a look at the code it seems that now URIVariables are handled by the server. @JKRhb can you verify if this is still an issue?

[JKRhb]

Hmm, I guess the problem here is that for HTTP, forms like

{
    "href": "http://plugfest.thingweb.io:8083/smart-coffee-machine/properties/availableResourceLevel{?id}",
    "contentType": "application/json",
    "op": ["readproperty", "writeproperty"]
},

are generated, while for CoAP, only forms like

{
    "href": "coap://plugfest.thingweb.io:5683/smart-coffee-machine/properties/availableResourceLevel",
    "contentType": "application/json",
    "op": ["writeproperty", "readproperty"]
},

without the actual URI variables are generated, right?

[JKRhb]

I guess we need to implement this function in the HTTP server also for the CoAP server or move it to the core package to use it across protocol binding implementations:

node-wot/packages/binding-http/src/http-server.ts

Lines 264 to 296 in c8177c2

	private updateInteractionNameWithUriVariablePattern(
	interactionName: string,
	uriVariables: PropertyElement["uriVariables"] = {},
	thingVariables: PropertyElement["uriVariables"] = {}
	): string {
	const variables = Object.assign({}, uriVariables, thingVariables);
	if (Object.keys(variables).length > 0) {
	let pattern = "{?";
	let index = 0;
	if (uriVariables) {
	for (const key in uriVariables) {
	if (index !== 0) {
	pattern += ",";
	}
	pattern += encodeURIComponent(key);
	index++;
	}
	}
	if (thingVariables) {
	for (const key in thingVariables) {
	if (index !== 0) {
	pattern += ",";
	}
	pattern += encodeURIComponent(key);
	index++;
	}
	}
	pattern += "}";
	return encodeURIComponent(interactionName) + pattern;
	} else {
	return encodeURIComponent(interactionName);
	}
	}

[egekorkan]

So it seems that it is just about the TD generation. Regarding core or not:

One issue I see with moving to core would mean that uri variables would be generated for all protocols, whether they support it or not. I am not convinced on myself but I think it would be better to manage forms as much as possible in the binding level 🤔

[JKRhb]

One issue I see with moving to core would mean that uri variables would be generated for all protocols, whether they support it or not. I am not convinced on myself but I think it would be better to manage forms as much as possible in the binding level 🤔

Oh, yeah, I was rather thinking about moving the function itself to the core package and then let the binding implementations use it in their implementations :) I now tried to implement the feature in #1078 – could you have a look if that resolves the issue?

[egekorkan]

moving the function itself to the core package and then let the binding implementations use it in their implementations :)

Ok that makes sense, thank you!