Paul Mossman wrote:
> Hi all,
>
> I'm considering adding a sipXconfig "Phone" Resource REST API. I need
> an API for XX-6490, and it looks like adding and using a REST server
> will not be much more work than creating a client to the existing SOAP
> API.
>
> 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.
> I feel queasy about two things though:
>
> 1. Can a successful PUT response communicate whether a new phone has
> been created, versus update of an existing phone?
No. You cannot do that with PUT.
If you really need that distinction design the interface that adds new
phones by accepting POST to /phone
You'll get a URI or an ID of a newly created object as a response (or error
if the entity already exists).
>
> 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.
Serial number or model cannot be changed in sipXconfig. You do need to
delete the phone and recreate it if for some reason its model have changed.
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 doesn't require either of these problems to be solved, but what
> I've proposed may introduce limitations. I am happy to just accept that
> this URI may be deprecated in the future.
>
>
> -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/
