prev_page_uri and next_page_uri values use "null", should that be null?

[peteroyle]

Hi,

When I'm paginating through Call records returned from the Calls.json endpoint I initially tried to detect the last page using StringUtils.isEmpty(nextPageUri), however this didn't work as expected because on the last page the value for next_page_uri is returned as the String "null". I added a check for "null" as a simple workaround, but I think my original code would have worked properly if RestComm returned null instead of "null" as the value for next_page_uri.

Example request: http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Calls.json

Response extract:

{ "page": 0, "num_pages": 1, "page_size": 50, "total": 73, "start": "0", "end": "49", "uri": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Calls.json", "first_page_uri": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Calls.json?Page\u003d0\u0026PageSize\u003d50", "previous_page_uri": "null", "next_page_uri": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Calls.json?Page\u003d1\u0026PageSize\u003d50\u0026AfterSid\u003dCAa28d1175c8844fe38dd1750770105f46", "last_page_uri": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Calls.json?Page\u003d1\u0026PageSize\u003d50", "calls": [ .........

Interested to know what you think, thanks.

[leftyb]

Hi peteroyle ,

We will revise your suggestion, and will update you the soonest possible. Thank you.

[leftyb]

Hi peteroyle,

We revised your suggestion. We will like to inform you that is not possible to apply what you are suggesting. The request returns a JSON object so it is not possible to use not quoted elements.

Thank you.

[peteroyle]

Hi @leftyb,

Thanks for considering my suggestion. I just wanted to point out that I disagree with you assertion that it's not possible to implement my suggestion. It's perfectly possible to return null as a value in JSON - in fact it's already happening in other places in RestComm. Take this sample response to the IncomingPhoneNumbers endpoint which I copied and pasted directly from output of the RestComm testsuite:

{ "sid": "PNd02c6e2590b84c32af4759faa6fe59c8", "account_sid": "ACae6e420f425248d6a26948c17a9e2acf", "friendly_name": "6798794", "phone_number": "+16418470436", "voice_url": "http://demo.telestax.com/docs/voice.xml", "voice_method": "GET", "voice_fallback_url": null, "voice_fallback_method": "POST", "status_callback": null, "status_callback_method": "POST", "voice_caller_id_lookup": false, "voice_application_sid": null, "date_created": "Thu, 16 Jul 2015 15:17:21 +1000", "date_updated": "Thu, 16 Jul 2015 15:17:21 +1000", "sms_url": null, "sms_method": "POST", "sms_fallback_url": null, "sms_fallback_method": "POST", "sms_application_sid": null, "capabilities": { "voice_capable": false, "sms_capable": false, "mms_capable": false, "fax_capable": false }, "api_version": "2012-04-24", "uri": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/IncomingPhoneNumbers/PNd02c6e2590b84c32af4759faa6fe59c8.json" }

Note the value of "voice_fallback_url" among others which are null. I suspect that the issue is with the CallDetailRecordListConverter.java file at lines 127,131 and 132 where "null" is returned as opposed to null (though I haven't had time yet to test this).

What do you think?

[otsakir]

Hi,

I think that returning the string 'null' for conveying the fact that a field is empty is a mistake. My only worry would be for existing clients that rely on this mistake.

I suggest put this to the reodmap and resolve it as time permits.

[leftyb]

Hi @peteroyle

Yes you are right, although i tested your suggestion, i mistakenly "missed" the fact that the functions getNextPageUri(CallDetailRecordList list) & getPreviousPageUri(), return a String value, so as it is implemented always the returned value in the case of an empty field must be a string 'null'. By that means, i thought that it is obligated to use quoted values in a JSON object. It is indeed correct to consider modify it as you suggest and @otsakir commented. One issue on the subject is that the XML and JSON data types, are using the same functions for the returning data, so it is necessary to consider using different functions for each of the data type, as it is done at the "IncomingPhoneNumbers" that you are referring.