Following are some examples of objects found in the API and which HTTP Methods to use with them.
| Location | HTTP Method | Description | HTTP Codes |
|---|---|---|---|
| objects/sipAccount | GET | list of all SipAccount objects | 200 |
| objects/sipAccount/ | GET | get SipAccount with given Uuid | 200 |
| objects/sipAccount | POST | create new SipAccount | 201 |
| objects/sipAccount/ | PUT | update existing sipAccount object | 204 |
| objects/sipAccount/ | PATCH | update/patch existing sipAccount object using JSON Patch | 204 |
| objects/sipAccount/ | DELETE | remove SipAccount with given Uuid | 204 |
| objects/sipAccount/{Uuid}/clone | POST | clone SipAccount | 201 |
| methods/echo | POST | call Echo method | 200 |
Every call can result in HTTP Codes 400, 403, 404,.. (HTTP status codes)
GET: webapi/http/objects/sipAccount/c66d5435-fadd-4117-bd8c-788bc72b04af
RESULT 200: {"uuid":"c66d5435-fadd-4117-bd8c-788bc72b04af","sipAccount": {"displayName":"Testaccount Zwei","user":"test_user","password":"test_password","domain":"192.168.178.1","publish":false,"registerInterval":60,"transport":"udp","enabled":false}}
POST: webapi/http/objects/sipAccount
RESULT 201: Location: "http://demo/webapi/http/objects/sipAccount/c66d5435-fadd-4117-bd8c-788bc72b04af"
See also: HTTP Methods
| Location | HTTP Method | Description | HTTP Codes |
|---|---|---|---|
| list/objects | GET | list of all ObjectClasses | 200 |
| list/methods | GET | list of all MethodClasses | 200 |
| schema/object/sipAccount | GET | get schema description for sipAccount object | 200 |
| schema/method/userSetPassword | GET | get schema description for userSetPassword method | 200 |
Exception types: internal, alreadyExists, notFound, notManagedHere, decode, value, locked, unauthorized, unlicensed, notImplemented
Example HTTP response body:
{
"type": "unauthorized",
"message": "Cannot delete root user."
}
Connection requires valid user session. Login is required before connecting to the socket server.
The event object signals is used to tell the server for which BaseObjects the create/update/destroy messages are sent to the client. Example data: ["sipAccount", "sipCall", "phoneBookEntry"]
The user session is managed though the session object.
HTTP POST for this object is the only method allowed without an active session.
There is always exactly one session object with the fixed Uuid 5ff1c07e-5cd7-4d94-94ef-79a28bb189e4
| HTTP Method | Description | HTTP Codes |
|---|---|---|
| GET | get session data | 200 |
| POST | login | 201, 401 |
| PUT | not implemented | 405 |
| DELETE | logout | 205 |
| HEAD | refresh session | 204 |
Examples:
POST webapi/http/objects/session '{"session": {"username": "root", "password": "ferncast"}}'
RESULT 201: Location: "http://demo/webapi/http/objects/session/5ff1c07e-5cd7-4d94-94ef-79a28bb189e4"
It's also possible to authenticate with an API key using the HTTP Authorization header and the Bearer scheme.
API keys are tied to users in order to enable the same flexible rights management.
Users can only update their own API keys.
Example:
GET "Authorization: Bearer API-KEY-GOES-HERE" webapi/http/objects/stream
An active login session or API key (see above) is required to make this call. The user needs the permission to call the MonitoringStats method.
aixtream uses a cursor to track monitoring calls. For the first time, when there is no cursor available yet, call:
GET http://aixtream-xyz/webapi/http/status
Besides the status data, this will return a cursor for the next call:
GET http://aixtream-xyz/webapi/http/status?cursor={Cursor}
This way aixtream knows which events and log entries have already been reported to the monitoring system and does not report them again. For alarms this does not apply because (in contrast to events and log entries) alarms have a state and exist as long as the underlying problem is not fixed.
See here for examples of API calls in aixtream.