Damian wrote:
...
> > The Resource will be a sipXconfig "Phone". i.e. An
> instance of items
> > in a Devices->Phones collection.
> >
> > Initially it will be kept very simple, just the operations and data
> > fields needed by XX-6490:
> >
> > /phone/{serial #}?model={model};description={description} - PUT
> >
> >
>
> This is probably not a good use of URI parameters.
> It would be better if model and description are be in the XML
> or JSON body.
OK.
> > 2. I'm not sure how you'd change an existing phone's Serial Number,
> > since it's the ID. Is there a best practice for doing this
> is REST?
> > (I don't think we'd want to delete, then re-create with a different
> > ID.) One solution would be to have opaque IDs assigned by
> the server,
> > and the serial # would be just another data field. But
> would be messy.
>
> Allowing the API to create new entity without knowing its id
> is quite standard behavior.
Now that I actually look at the phone relation in the DB, it already has
a "phone_id" field, likely available from phone.getBeanId(). That can
be used as the ID (though XX-6490 won't need it.)
XX-6490 will require:
/phones (Phone collection) - POST, where an example XML body would
be:
<phone>
<serialNumber>0004f21ed0d3</serialNumber>
<model>polycom650</model>
<description>Auto-provisioned on 28 Sept 2009 \n ID: SU7
S6T\n Model: SoundPoint IP 650</description>
</phone>
In the future an individual Phone resource would have the URI structure:
/phones/{phone_id}.
> Serial number or model cannot be changed in sipXconfig.
True for model, but not for Serial number.
Being able to change the serial number I think is a rather useful
feature. When equipment needs to be swapped the superadmin just gets a
new phone (of the same model), changes the MAC of the existing Phone
entry, and then deploys.
> However specifically for XX-6490 I am not sure you should be
> deleting any existing phones. If the phone is already
> configured it needs to stay in sipXconfig.
XX-6490 will not delete phones.
Thanks.
-Paul
[email protected]
_______________________________________________
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/
