REST API returns formatted state value, not useful programmatically

Setup, Configuration and Use Runtime
1

@igor reported that the REST API returns a formatted version of the PointType state, which may look nice but is not useful to an API consumer (like his new client app, for example) because the values are rounded to two decimal places and they have ° signs in them an other cruft from the perspective of code consuming the value. This is because the REST API is calling PointType.toString():

	@Override
	public String toString() {
		return String.format("%1$.2f°N, %2$.2f°W, %3$.2f m", latitude, longitude, altitude);
	}

Would it not be better if the REST API used the ComplexType.getConstituents() method and then walked the returned SortedMap so that there is no formatting to contend with by the API consumer? Something like:

<item>
<type>LocationItem</type>
<name>MyLocation</name>
<state>
  <constituent key="lat">33.6232833</constituent>
  <constituent key="long">-18.8985063</constituent>
  <constituent key="alt">0.00</constituent>
  <!-- or whatever is properly parseable using XML or JSON to structure it -->
</state>
<link>http://localhost:8080/rest/items/MyLocation</link>
</item>

Returning formatted state values like this in the REST API will be a long-term problem unless some standard approach is made to make the returned state fully usable.

This may be an issue to address in OH2, but I think it needs some attention. Thanks!

2

This is actually an issue that needs to be discussed at Eclipse SmartHome, since the code resides there.
And yes, I actually exactly complained about this already in June, see https://github.com/eclipse/smarthome/pull/222#discussion_r33571685.
It seems that was left unheard, so I will try to revive the discussion there.

4

So according to https://github.com/eclipse/smarthome/pull/222#issuecomment-158912461, the REST API does not return a formatted value, but a comma-separated one. Testing this on openHAB 2, I also see

{
                  "widgetId": "0202_3",
                  "type": "Frame",
                  "label": "Map/Location",
                  "icon": "frame",
                  "mappings": [],
                  "widgets": [
                    {
                      "widgetId": "0202_3_0",
                      "type": "Mapview",
                      "label": "Brandenburg Gate Berlin",
                      "icon": "mapview",
                      "mappings": [],
                      "height": 10,
                      "item": {
                        "link": "http://localhost:8080/rest/items/DemoLocation",
                        "state": "52.5200066,13.4049540",
                        "type": "LocationItem",
                        "name": "DemoLocation",
                        "label": "Brandenburg Gate Berlin",
                        "tags": [],
                        "groupNames": []
                      },
                      "widgets": []
                    }
                  ]
                }

@watou, @igor: Are you referring to an older version? Can you try with the latest sources?

5

@igor first spotted the problem in OH1, so that’s where I opened a PR which uses the identical toString() method as in the ESH version. I also idly considered other possible parsing issues for ComplexTypes in general, so mentioned it might have bearing on OH2. However, since BigDecimal.toPlainString() uses a hardcoded . as a decimal separator, I don’t think there are parsing issues going from toString() output to valueOf(String) construction, which ought to be the rule for all Types.

6

Then I understand that this issue is closed (or does not exist) for ESH/OH2 - am I right ?

7

That’s my understanding as well.

8

Same here. My point in flagging this for “openHAB 2” was based on a concern, not realizing ESH had already been fixed but OH1 hadn’t.