Wiki source code of Websocket API Documentation (Event)
Version 39.1 by michaely on 2015/07/13 19:35
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | {{layout}} | ||
2 | {{layout-section ac:type="two_right_sidebar"}} | ||
3 | {{layout-cell}} | ||
4 | {{info}} | ||
5 | The information on this page applies to **iSymphony 3.2+**. | ||
6 | {{/info}} | ||
7 | |||
8 | = (% style="color: rgb(0,0,0);" %)Description(%%) = | ||
9 | |||
10 | The websocket API provides realtime events about the current state of the iSymphony server. External applications can utilize this API to integrate with the iSymphony server, by reacting to events pertaining to users, and call state. In conjunction with the CRM widget, this API can also be utilized to create custom widgets for the iSymphony client interface. | ||
11 | {{/layout-cell}} | ||
12 | |||
13 | {{layout-cell}} | ||
14 | {{panel title="On this page:"}} | ||
15 | |||
16 | |||
17 | {{toc maxLevel="2" indent="1"/}} | ||
18 | {{/panel}} | ||
19 | {{/layout-cell}} | ||
20 | {{/layout-section}} | ||
21 | |||
22 | {{layout-section ac:type="single"}} | ||
23 | {{layout-cell}} | ||
24 | = Object IDs = | ||
25 | |||
26 | Most events generated by the event API will contain UUIDs that can be used to identify objects the event relates to. Some events will reference multiple ids. These UUIDs are the same ids that are used to reference resources in the [[Live REST API>>doc:Live API]], allowing collaboration between the Live REST API and the Event API. | ||
27 | |||
28 | |||
29 | |||
30 | {{note title="Note on UUID persistance"}} | ||
31 | The UUIDs do not persist across restarts of the iSymphony server. If the server is restarted, the objects will contain new UUIDs. Also, if an object is destroyed then re-added, even with the same configuration, the UUID that represents that object will be different from the original. | ||
32 | {{/note}} | ||
33 | |||
34 | = Accessing Resource Instances By Symbolic Name = | ||
35 | |||
36 | In addition to accessing resource instances by UUID, resource instances can also be accessed by their symbolic name. Most, but not all resources contain a symbolic name. The path section **getByName** can be used to access a resource instance by it symbolic name. Documentation for a specific resource will specify, if the resource can be accessed by symbolic name, and what the symbolic name property is. | ||
37 | |||
38 | == Examples == | ||
39 | |||
40 | The following path will access an extension with extension number 4224, in a core server with a slug of default. | ||
41 | |||
42 | {{code}} | ||
43 | http://localhost:58080/communication_manager/rest/live/coreServers/getByName/default/extensions/getByName/4224 | ||
44 | {{/code}} | ||
45 | |||
46 | \\ | ||
47 | |||
48 | You can mix and match UUIDs and getByName in the REST URLs, like so: | ||
49 | |||
50 | {{code}} | ||
51 | http://localhost:58080/communication_manager/rest/live/coreServers/getByName/default/extensions/ef2faba9-8557-49c1-9ffc-5a71f41c7a23 | ||
52 | {{/code}} | ||
53 | |||
54 | == Document Notation == | ||
55 | |||
56 | When a parent resource path can be access by UUID and getByName, the path in the documentation will specify the following format: | ||
57 | |||
58 | {{code}} | ||
59 | [{UUID} | getByName/{symbolic_name}] | ||
60 | {{/code}} | ||
61 | |||
62 | This specifies that the instance can be accessed via "UUID" OR "getByName/symbolic_name". {UUID} and {symbolic_name} will be replaced with more specific names. | ||
63 | |||
64 | = REST Resources = | ||
65 | |||
66 | The Live API exposes several REST resources, that allow access to the current state of specific objects in the system. All current live resources are listed below. Details concerning each resource, and their actions, can be found within the individual resource documentation pages. | ||
67 | |||
68 | == Resource List == | ||
69 | |||
70 | |||
71 | |||
72 | {{children/}} | ||
73 | |||
74 | == Notes on Resource Documentation == | ||
75 | |||
76 | Due to the interdependent nature of resources in the system, the resource path information in the documentation is split into several sections. Paths in a specific section may relate to, or require, paths specified in other sections. | ||
77 | |||
78 | * **Root Resource Paths : **Specifies paths that can be used to access sets (multiple instances) of a resource, in relation to a parent resource. | ||
79 | * **Instance Resource Paths : **Specifies paths that can be used to access a specific instance of a resource. These paths require a **Root Resource Path**, in most cases, but not all. | ||
80 | * **Sub Resource Paths : **Specifies paths that provide access to the child resources, of a specific resource instance. These paths require an **Instance Resource Path.** | ||
81 | * **Action Paths: **Specifies paths that are used to perform actions on a specific resource instance. These paths require an **Instance Resource Path.** | ||
82 | |||
83 | \\ | ||
84 | {{/layout-cell}} | ||
85 | {{/layout-section}} | ||
86 | {{/layout}} |