Returns 200 when querying historic data for non existing attribute

[YatinArora-NEC]

When executing the GET request of STH API for return historic information for non existing attribute, it returns 200 OK

{
    "contextResponses": [
        {
            "contextElement": {
                "attributes": [
                    {
                        "name": "splid",
                        "values": []
                    }
                ],
                "id": "Room5",
                "isPattern": false,
                "type": "Room"
            },
            "statusCode": {
                "code": "200",
                "reasonPhrase": "OK"
            }
        }
    ]
}

The request is made by using

http://sth-host/STH/v1/contextEntities/type/Room/id/Room5/attributes/splid?hLimit=4&hOffset=0
and following are the logs:

time=2019-06-05T01:24:27.970Z | lvl=DEBUG | corr=a43fb9b1-ed50-4de4-9960-b9bace773ce5 | trans=a43fb9b1-ed50-4de4-9960-b9bace773ce5 | op=OPER_STH_GET | from=n/a | srv=testdb | subsrv=/testservicepath | comp=STH | msg=No raw data available for the request: /STH/v1/contextEntities/type/Room/id/Room5/attributes/splid?hLimit=4&hOffset=0

I have made subscriptions for two attributes that is pressure and temperature ,but when I make request for non existing attribute splid it give 200 OK.

But it should return 404 Not Found as the attribute does not exist for which the request is made.

[fgalan]

Thanks for your report!

However, I'm a bit unsure of what we should do regarding this... From a formal point of view, I agree that 404 Not Found would be more correct. However, if we change this maybe we are impacting in all the STH clients that have been used the API for years with the current behavior. And the gain would not be really too much (only to make STH slightly more "formal" with regards to API REST).

In this kind of situations, I tend to prefer backward compatibility security over API REST formality.

What do you think? What do other people think? Feedback is welcome!

[YatinArora-NEC]

Hi @fgalan, @AlvaroVega
As per my understanding the "404 Not Found" status code must be implemented for this issue as formal behavior of API and also sometimes the user may get confused about the empty values as 200 status code is returned. Also we can update the documents for these changes.
So can we implement the "404 Not Found" status code for both issues( #511 and #435 )?

[fgalan]

As per my understanding the "404 Not Found" status code must be implemented for this issue as formal behavior of API and also sometimes the user may get confused about the empty values as 200 status code is returned. Also we can update the documents for these changes.
So can we implement the "404 Not Found" status code for both issues( #511 and #435 )?

But in that case backward compatibility would not be preserved, would it?