Paul Mossman wrote:
> Hi all,
>
> Damian and I were discussing this on Friday. We both think it's the
> best way for sipXprovision to use sipXconfig's phone config generation
> capabilities.
>
> I originally assumed it would be preferable to retrieve all the config
> files in a single REST request. But Polycoms do an HTTP GET for each
> file, so there should be one REST request for each file. (sipXprovision
> could only make use of multiple files in the REST response if it
> persisted the content between Polycom HTTP GET requests.)
>
> So given that there will be one REST request per config file, does this
> make sense?
>
> /phone/{phoneId}/profile/{name} - GET
>
> Where the body of the HTTP response would be the configuration file
> verbatim.
>
> ID would be the "phone_id" field of the same name from DB, likely
> available from phone.getBeanId(). (See
> http://list.sipfoundry.org/archive/sipx-dev/msg19801.html )
actually getBeanId does not return unique id, getId does
>
>
> Note that each configuration file name is unique not only within the
> phone, but also within system. A /phone/profile/{name} resource URI
> would be possible. But sipXconfig would need to know how to extract the
> serial number from every form of configuration file, which doesn't sound
> practical.
>
> So given that the REST client will be specifying the Phone ID, the REST
> API must have a way for it to be discovered. Perhaps:
>
> - /phone?serialNumber={serialNumber} GET to query for a phone by serial
> number. Example response XML body:
> <phone>
> <phoneId>4</phoneId>
> <serialNumber>0004f21ed0d3</serialNumber>
> <model>polycom650</model>
> <description>Some text...</description>
> </phone>
make sense - but read on...
>
> - /phone POST must return the ID, regardless of whether the Phone was
> just created or already existed. This would be in an XML body, the same
> as above.
>
> - /phone/{phoneId} GET should return the same XML body as above.
> (sipXprovision won't need this GET, but it seems useful to have for
> consistency.)
>
>
Wouldn't it be more convenient for the caller if we used 'serial number'
instead of 'phone id'?
The caller could just issue:
GET /phone/{serialNumber}/profile/{name}
Also
GET /phone/{serialNumber}/profile
Needs to retrieve the list of profiles (for completeness).
D.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
