Latest revision as of 05:37, 4 February 2020

TelcoBridges HTTP RESTful Northbound Interface

Introduced in version 2.9, the RESTful API allows the provisioning of a Tmedia VoIP gateway or a Tdev development platform. The configuration of the device is seen as collections of resources than can be queried/modified through this interface.

HTTP requests are sent to the web server using standard HTTP methods(e.g., GET, PUT, POST, or DELETE). Data exchanged in requests and responses is in JSON format.

Supported RFCs

TelcoBridges supports the following RFCs for RESTful API:

REST API overview

Supported Methods

GET

List elements of a collection

 GET /users
 <- Content : {"root":{}}
 <- Code    : HTTP/1.0 200 OK

Read a specific element

 GET /users/root
 <- Content : {"name":"root","user_group":"Admin","pass":"Not Shown"}
 <- Code    : HTTP/1.0 200 OK

PUT

Update a configuration element

 PUT /users/root
 -> Content : {"pass":"MyNewSecret"}
 <- Code    : HTTP/1.0 200 OK

Omitted attributes in a PUT are left unchanged on the server.

POST

Create a configuration element into a collection

 POST /users
 -> Content : { "name" : "RogerFluffy", "user_group" : "nobody" , "pass" : "xyz" }
 <- Code    : HTTP/1.0 200 OK

Omitted attributes in a POST are being set to the 'default' value.

DELETE

Delete a configuration element from a collection

 DELETE /users/RogerFluffy
 <- Code    : HTTP/1.0 200 OK

Elements

Elements are found under collection URIs. A collection is generally composed of multiple elements, with a different name for each element. The element name must be provided during the POST:

 POST /users
 -> Content : { "name" : "RogerFluffy", ... }
 <- Code    : HTTP/1.0 200 OK

Elements generally have attributes, and can also include collections. For example, for the configuration element MyCFG, we can find the routes collection using the following URI:

 /configurations/MyCFG/routes

Collections

URI with the plural form generally represent a collection of elements. A collection can be composed of mutiple elements, or limited to 1.

For example, configuration are found under the following collection URI

 /users

Likewise, the list of routes can be found on

 /configurations/MyCFG/routes

When the collection is limited to 1 element, the element name is fixed. For example, only one H.248 stack can be defined, therefore the name is fixed to gateway_h248 The element name must be NOT be provided during the POST:

 POST /configurations/MyCFG/h248_stacks
 -> Content : { "enabled" : true, "naps" : [ "NAP_TDM", "RTP_NAP"], ... }
 <- Code    : HTTP/1.0 200 OK

Recursivity

Non-recursive GET requests (default)

By default, requests are non-recursive. This means that when a GET request is made on a URI, only objects on that element will be returned.

 GET /configurations/NewCFG
 <- Content : {"name":"NewCFG", "notes":"This is a new demo configuration", "routes":{}, ... }

In the response, we see two attribute value pairs : name and notes, along with another object named routes. The later is a collection, and should be queried individually to get its sub-elements.

 GET /configurations/NewCFG/routes
 <- Content : {"Route1":{}, ...}
 GET /configurations/NewCFG/routes/Routes1
 <- Content : {"name":"Route1", "called":"5551212","calling":"", ...}

Recursive GET requests

It is possible to get all sub-elements from a GET by using the recursive=yes attribute on the URI.

 GET /configurations/NewCFG?recursive=yes
 <- Content : { 
      "name":"NewCFG", 
      "notes":"This is a new demo configuration", 
      "routes": { 
        "Route1": {
          "name":"Route1", 
          "called":"5551212",
          "calling":"", ...
        },
        "Route2": {
          "name":"Route2", 
          "called":"5551314",
          "calling":"", ...
        }, ...
      }
    }

This is also true to get the content of all elements of a collection

 GET /users?recursive=yes
 <- Content : {
      "RogerFluffy":{
        "name":"RogerFluffy",
        "user_group":"nobody",
        "pass":"Not Shown"
      },
      "root":{
        "name":"root",
        "user_group":"Admin",
        "pass":"Not Shown"
      }
    }

Note : recursive GET does not apply to status elements.

Recursive PUT/POST requests

The recursivity of a PUT/POST depends on the content. It is possible to specify the content of all sub-elements under a URI. For example, to change the complete routing table, we could do something like:

 PUT /configurations/NewCFG/routes
 -> Content : {
        "Route1": {
          "name":"Route1", 
          "called":"5551212",
          "calling":"", ...
        },
        "Route2": {
          "name":"Route2", 
          "called":"5551314",
          "calling":"", ...
        }, ...
      }
    }

Or even change a complete configuration in a single PUT

 PUT /configurations/NewCFG
 -> Content : { 
      "name":"NewCFG", 
      "notes":"This is a new demo configuration", 
      "routes": { 
        "Route1": {
          "name":"Route1", 
          "called":"6661212",
          "calling":"", ...
        },
        "Route2": {
          "name":"Route2", 
          "called":"6661314",
          "calling":"", ...
        }, ...
      }
    }

Documentation

It is possible to get the documentation for the attributes of an element from a GET by using the documentation=true attribute on the URI, either for the collection, an element or a new element.

 GET /configurations?documentation=true
 GET /configurations/NewCFG?documentation=true
 GET /configurations/new?documentation=true
 -> Content : {
        "name": {
          "description" : "Name of this configuration.", 
          "type" : "text",
        },
        "notes": {
          "description" : "Free text field available to add any system/configuration information (this field is ignored by the system)", 
          "type" : "text",
        }, ...
      }
    }

Recursive Documentation

It is possible to get documentation recursively by using both the documentation=true and the recursive=yes attributes on the URI.

 GET /configurations?documentation=true&recursive=yes
 -> Content : { 
      "name": {
          "description" : "Name of this configuration.", 
          "type" : "text",
      }, 
      "notes": {
          "description" : "Free text field available to add any system/configuration information (this field is ignored by the system)", 
          "type" : "text",
      }, 
      "routes": { 
        "called": {
          "description" : "Called number to match this route. Leave empty to match any called number.", 
          "type" : "text",
        },
        "calling": {
          "description" : "Calling number to match this route. Leave empty to match any calling number.", 
          "type" : "6661314",
        }, ...
      }, ...
    }

Request Status code

The following result class are used to as HTTP status code to indicate the result of request.

* 2XX - success
* 3XX - redirection (304 Not Modified)
* 4XX - client error
* 5XX - server error

In Addition to HTTP status code, every HTTP response also inlcudes a JSON payload with a verbose message.

 POST /configurations/MyCFG/h248_stacks
 -> Content : { ... }
 <- Code    : HTTP/1.0 200 OK
 <- Content : { "message" : "Tbgw h248 cfg creation failed: Public ip address can't be blank, Public ip address is invalid, Local ip address is invalid, Local ip address When not using virtual ip, an ip address must be entered"}

This message can be used to find the exact reason why a RESTful API call failed.

HTTP headers

The following HTTP header should be used in requests:

The following HTTP header are to be expected for a server response:

API Access

HTTP port

The HTTP port for RESTful access is the same as for the Web interface. By default, HTTP port is 12358. Therefore the RESTful URIs should looks something like:
http://TMG_IP_ADDR:12358/@[collection_name]/@[resource_name]

Credentials

The credentials (user/password) used to authenticate a RESTful client application are the same as for the WebPortal. Users can be managed from the Web interface under /users. The same path is used to manage users by the RESTful interface.

Ruby implementation example

This ruby script is an example of how to use TelcoBridges RESTful Northbound Interface.

• The script can be executed from any computer having access to the management web interface.
• The script can also be copied on the internal host of a Tmedia and executed from a SSH client (as shown in the examples below using 127.0.0.1:12358).

Download script

• httprestapi.rb [click to download]

Usage

./httprestapi.rb <URI> <user> <password> <http request>

  With <URI> = http://ip:port
    Example: ./httprestapi.rb 'http://127.0.0.1:12358' 'root' 'password' <http request>

  With <http request> = <GET|PUT|POST|DELETE> <element path> [json | -i jsonfile | -o jsonfile]
    -i jsonfile = input json file used for PUT or POST http request
    -o jsonfile = output json file used for GET http request

GET

Get the configuration collection list and display the JSON returned in the body of the HTTP response.

./httprestapi.rb 'http://127.0.0.1:12358' GET '/configurations'

Show the use of "recursive=yes" to get all sub-element of configuration. Put the returned JSON in "test_configuration.json" file.

./httprestapi.rb 'http://127.0.0.1:12358' GET '/configurations/test?recursive=yes' '-o test_configuration.json'

Use "documentation=yes" to return documentation of all attributes of an element. Below example returns documentation for a new route element.

./httprestapi.rb 'http://127.0.0.1:12358' GET '/configurations/test/routes/new?documentation=yes'

Get request can also be used to retrieve the status of some elements of the active configuration.

./httprestapi.rb 'http://127.0.0.1:12358' GET '/configurations/test/naps/xtel/status'

PUT

Modify attributes of an element. Below example renames the route element named "Test" to "NewName".

./httprestapi.rb 'http://127.0.0.1:12358' PUT '/configurations/test/routes/test_route' '{"name":"new_route_name"}' 

Modify attributes of an element using a JSON file for the HTTP request.

./httprestapi.rb 'http://127.0.0.1:12358' PUT '/configurations/test/routes/test_route' '-i modified_route.json' 

Activate "demo" configuration

./httprestapi.rb 'http://127.0.0.1:12358' PUT '/systems/system_1' '{"target_configuration":"demo"}' 

POST

Create a new element. Below example add a new route named "xtel_to_SBC_1".

./httprestapi.rb 'http://127.0.0.1:12358' POST '/configurations/test/routes' '{"name":"xtel_to_SBC_1","nap":"xtel","remapped_nap":"SBC_1"}' 

Create a new element using a JSON file for the HTTP request.

./httprestapi.rb 'http://127.0.0.1:12358' POST '/configurations/test/routes' '-i new_route.json' 

Create a new configuration using a JSON file for the HTTP request.

./httprestapi.rb 'http://127.0.0.1:12358' POST '/configurations' '-i test_configuration.json' 

DELETE

Delete an element. Below example delete the route named "xtel_to_SBC_1".

./httprestapi.rb 'http://127.0.0.1:12358' DELETE '/configurations/test/routes/xtel_to_SBC_1' 

Using JSON files

Modify an element

1. Get route configuration in JSON file

./httprestapi.rb 'http://127.0.0.1:12358' GET '/configurations/test/routes/test_route' '-o routes.json'

2. Edit JSON file attributes

vi route.json

3. Modify element from JSON file

./httprestapi.rb 'http://127.0.0.1:12358' PUT '/configurations/test/routes/test_route' '-i routes.json'

Create a new element

1. Get an element default attributes value in a JSON file

./httprestapi.rb 'http://127.0.0.1:12358' GET '/configurations/test/routes/new' '-o routes.json'

2. Edit JSON file attributes

vi route.json

3. Create new element from JSON file

./httprestapi.rb 'http://127.0.0.1:12358' POST '/configurations/test/routes/new_route' '-i routes.json'

Postman tool integration

Postman is an API(application programming interface) development tool provided by third party that helps to test APIs. Almost any functionality that could be needed by any developer is encapsulated in this tool. It has the ability to make various types of HTTP requests(GET, PUT, POST, DELETE).

• Postman tool is another example of how to use TelcoBridges RESTful Northbound Interface.
• The application tool can be run from any computer having access to the management web interface.

Download application

• Get postman

Usage

• When sending HTTP requests to Telcobridges management interface for manipulating with Telcobrigdes configurations' resources, the HTTP request must be following the HTTP headers as listed above.
• Out of these headers, besides Host information and Authorization, Content-Type is important, and must be specified as "application/json" in order to return right result
• Other headers are either already complying or optional, and becoming less important when using default headers values as provided by Postman

GET

Include the authorization with "Basic Auth",

Get the configuration collection list and display the JSON returned in the body of the HTTP response.

PUT

Modify attributes of an element. Below example renames the route element named "Test_Codec" to "Test_Codec1".

• With the authorization and header set like GET
• Specify the route name that will have name changed, in this case, "Test_Codec"
• Go to "Body" tab, click "raw", and select "JSON"
• Copy the new name parameter as {"name":"Test_Codec1"}
• Press Send, and will receive 200OK

POST

Create a new element. Below example add a new route named "xtel_to_SBC_1".

• With the authorization and header set like GET
• Specify the route name to be added, in this case, "xtel_to_SBC_1"
• Go to "Body" tab, click "raw", and select "JSON"
• Copy the new name parameter as {"name":"xtel_to_SBC_1","nap" : "Test_Codec","remapped_nap" : "NAP_SS7_7443"}
• Press Send, and will receive 200OK

DELETE

Delete an element. Below example delete the route named "xtel_to_SBC_1".

PUT (for activate configuration)

Activate a configuration. Below example is to put (thus activate configuration) for the configuration named "Config_test_CDR".

• system name, in this case, is "support_lab_tmg3200"

References

• Introduction to Postman for API Development
• Postman tutorial
• Get postman