Make IDE HTTP server setVar return the the value

[Simon Walters]

Made new issue as I realised that no-one gets notified on extra posts on a resolved issue

One thing - the new way of setting a variable doesn’t produce any return value like it used to - was that a deliberate design decision or a missing feature?

‌

‌

[Bernat Romagosa]

It doesn’t return any value by design, but maybe that could be changed. @John Maloney , any strong opinions?

[John Maloney]

I don’t have a strong opinion. However, the WebThing spec (https://webthings.io/api/#property-resource) says that the PUT request that sets a property is supposed to return a JSON object containing the property name and value, so we should probably do that if it doesn’t add a huge amount of overhead or code.

[Bernat Romagosa]

Hi, John. We’re talking about the plain HTTP server, the one in the IDE

[John Maloney]

Are you sure? That new HTTP server doesn’t support PUT requests or the /properties/ URL format as shown in the Snap! blocks.

If we are talking about the new HTTP server built into the IDE then, yes, I do have a strong opinion. It does not return the value by design. The caller can store the value in a Snap! variable if they want, or do a getVar request to check that it was actually updated.

[Bernat Romagosa]

Hmm, you’re right. But the issue title mentions “micro:bit”, so there’s something wrong here. @Simon Walters can you clarify?

[Simon Walters]

Previous thread for reference

https://bitbucket.org/john_maloney/smallvm/issues/202/problem-with-http-server-on-microbit

‌

[Simon Walters]

I am talking about the IDE HTTP server previously called WebThings server before the change on 31Dec20

The old version did return a JSON object.

I think that is good thing to do and unless it carries a large overhead, I’d like to see it reverting to previous behaviour.

[John Maloney]

The old HTTP server was based on the WebThing REST API, which was built around JSON. The new HTTP server is not based on the WebThing API. It is much simpler and doesn’t use JSON encodings. The print strings for short lists use square brackets, making them look a bit like JSON, but that’s just a coincidence.

I’d want to keep the new HTTP server simple and lean.

What’s the use-case for returning a value from the setVar operation?

[Simon Walters]

Use case is just less change to my existing one liner in Snap!

I can live without it

I’ll carry on documenting my project with new method

‌

[John Maloney]

Thanks for sending that code. I agree, that is a little awkward.

How would it be if the setVar call just echoed the value – i.e. everything after “setVar/cheerlights/” in the original request. It wouldn’t be a JSON object as it was with the old WebThings server, but it would be the value of cheelights that is stored into the “return” variable in your new implementation.

[Simon Walters]

That would be great :)

[Simon Walters]

Could I ask that this issue is addressed in for the next release please? :)

[John Maloney]

Yep, it’s fixed in 1.0.12 just released.