Account API response "uri" property inconsistent with actual uri

[otsakir]

The RESTfull response when retrieving an account has a minor inconsistency in the uri field. It returns:

"uri": "/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf.json",

while the endpoint expects:

"uri": "/2012-04-24/Accounts.json/ACae6e420f425248d6a26948c17a9e2acf",

It comes down to the fact that the Accounts REST API is defined a little differently from other APIs.

[abdulazizali77]

@otsakir ill take it However, it must be noted that the twilio API returns uri with .json suffix

"uri": "/2010-04-01/Accounts/ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.json"

@deruelle any comments? i think this is related to #898 somewhat

[deruelle]

@abdulazizali77 great ! assigned to you

[deruelle]

@abdulazizali77 would you be ready to take on #898 as well to fix our API inconsistencies in that regard ?

[abdulazizali77]

@deruelle I will start looking into it!

[otsakir]

@abdulazizali77, @deruelle, i went through the PR and also ran a couple of manual tests to see the responses directly. The response is still not quite right.

I requested my account:

curl 'http://this:8080/restcomm/2012-04-24/Accounts.json/ACae6e420f425248d6a26948c17a9e2acf'

and got this response

{
  "sid": "ACae6e420f425248d6a26948c17a9e2acf",
  "friendly_name": "Default Administrator Account",
  "email_address": "administrator@company.com",
  "type": "Full",
  "status": "active",
  "role": "Administrator",
  "date_created": "Tue, 24 Apr 2012 00:00:00 +0300",
  "date_updated": "Mon, 16 Jan 2017 12:31:02 +0200",
  "auth_token": ...
  "uri": "/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf",
  "subresource_uris": {
    "available_phone_numbers": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/AvailablePhoneNumbers.json",
    "calls": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Calls.json",
    "conferences": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Conferences.json",
    "incoming_phone_numbers": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/IncomingPhoneNumbers.json",
    "notifications": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Notifications.json",
    "outgoing_caller_ids": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/OutgoingCallerIds.json",
    "recordings": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Recordings.json",
    "sandbox": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Sandbox.json",
    "sms_messages": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/SMS/Messages.json",
    "transcriptions": "/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Transcriptions.json"
  }
}

Note the uri: "uri": "/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf"

This url will return the xml version of the account.

The correct version (i.e. what the endpoint expects) would be: "uri": "/2012-04-24/Accounts.json/ACae6e420f425248d6a26948c17a9e2acf"

Btw, i noticed that the Resource uri starts with /2012-04-24/Accounts... while the subresource urls start with /restcomm/2012-04-24/Accounts... and created issue #1723

[ammendonca]

This has been fixed, it's currently returning expected uri: "/2012-04-24/Accounts.json/<SID>"