Possible wrong format in errorCode for pagination

[FiwareULPGC]

Using the pagination feature with details param enabled we get an errorCode like:

XML version

<errorCode>
    <code>200</code>
    <reasonPhrase>OK</reasonPhrase>
    <details>Count: 322</details>
</errorCode>

JSON version

"errorCode" : {
    "code" : "200",
    "reasonPhrase" : "OK",
    "details" : "Count: 322"
 }

We have a doubt with the details field, it seems to be a general field and it hasn’t a specific format. The “problem” resides in that “Count” isn’t a field. For example, if the JSON version is used by javaScript function, get the numbers of elements is something like:

    //data has the orion response
    var elements  =parseInt(data.errorCode.details.replace(“Count: ”,””));

If “Count” could be a property the functions would be something like:

    //data has the orion response
    var elements  =parseInt(data.errorCode.details.Count);

Although according to the official documentation actual approach seems to be the desired behavior, the second approach may be more coherent with the JSON structure. If details field could have more information at same time, getting the number of elements will be harder.

[kzangeli]

The problem is that if we add a field to the StatusCode (errorCode) we don't follow the OMA NGSI specification.
What we could do perhaps is to remove the 'Count: ' and just respond with

"details": 322

That way its usage would be easier in json, I imagine:

var elements  =parseInt(data.errorCode.details) ?

[fgalan]

OMA spec 5.5.14 on StatusCode (and ErrorCode is an instance of StatusCode) specifies Details is type "xs:any". Thus, using subfields is allowed by OMA NGSI.

I think the actual problem is backward compability. If we change this, automatically all the current client implementations using pagination will fail.

Probably this would be something to take into account for our next opportunity to break backward compability in an ordered manner, i.e. API "v2".

[fgalan]

It has been taken into account in APIv2 with the X-Total-Count header (see #947). Thus, this issue can be closed. Any futher comment (welcomed! :) should be included in issue #947