Enhancement request - return full paths to objects

[ssteiner]

At present, using O2G for doing PBX object manipulations requires intimate knowledge about the internal data structure of the OXe, notably paths.

Let's take hunting groups as an example. You get the model by GET'ing on /model/Station_Group". You list all Huntgroups by GET'ing on /Station_Group.

Nowhere does it tell you that to extract a single hunting group, you GET on /Group/1/Station_Group/{directoryNumber}. IMHO, the path should be returned on the model and ideally also in the list. I knew a few REST APIs where the list returns you the path to the individual objects. In order to retain compatibility, I propose to extend the model with a new property that gives the full path. E.g. when extracting the huntgroup, the PbxObject would have a new string property called ObjectPath which would contains "Group/1/Station_Group". So you can take the existing ObjectId and ObjectPath to generate the full path the object. {ObjectName}/{ObjectId} works for some objects but not for others... my approach would make it possible to use the same path construction for all objects regardless of the object hierarchy.

[yblanchard]

SumUp of the pb
==============
some objects like Station_Group url path cannot be built only from the result of the previous request.
For example,
a GET ../pbxs/{nodeid}/instances returns the list of first level of sub-objects like Subscriber or Group but no GET action on ../pbxs/{nodeid}/instances/Group can be performed because GROUP is not instanciable object, and therefore there is no obvious way to get for example the Station_Group object which are a subobject of Group, without MIB knowledge.
The second wish is to directly get the full path in the response.

what improvment can easily be done
===============================

GET ../pbxs/{nodeid}/instances
will return the attributes of the pbx and the set of the first level of all instanciables subObjects,
(instead of returning the first level of subobject, mixing instanciable and non instanciable objects)

for example

- "Entity_Parameters",
- "Subscriber"
- "Group/1/Pickup_Group" (and no longer "Group" which is not a "get-able" object)
- "Application_Configuration/1/ACD2/1/ACD2_Processing_Group"
- ...

In the same way,
GET ../pbxs/{nodeid}/instances/.../InstanciableObject/{id}
will return in addition of the attributes of the instance, the set of the first level of all instanciables subObjects if they exist

In that way, it allows to make a GET on each of theses objects just by concatenation of the origin path + the relative object path



GET ../pbxs/{nodeid}/instances/.../InstanciableObject/ is unchanged and
returns the list of instance identifiers



About returning full path of each instance directly in the response:

Even if it is a common REST practise, it is not very interesting since it can easily built by concatenation by the application.
Moreover, for huge number of instances (for instance, Subscriber), it will unnecessarily increase the response size, and so the performance.