[asterisk-dev] [Code Review] 3278: ari: create bridges with specified unique id

[Matt Jordan]

> On March 1, 2014, 5:41 p.m., Paul Belanger wrote:
> > /branches/12/rest-api/api-docs/bridges.json, lines 50-56
> > <https://reviewboard.asterisk.org/r/3278/diff/1/?file=54950#file54950line50>
> >
> >     After reading Matts comments, this still doesn't make sense.
> >     
> >     We are going to do POST /bridges and pass both bridge ID and name.
> >     
> >     But POST /bridges/{bridgeId} or PUT makes more sense.  Since you even have the /bridges/{bridgeId} name space already, we should be just creating the bridge with the ID passed.
> >     
> >     POST /bridges should be use when you want asterisk to generate the UUID for channel, and POST /bridges/{bridgeId} when you want to override it.
> 
> Matt Jordan wrote:
>     That I agree with :-)
>     
>     POST /bridges/{bridgeId} should just create the bridge - specifying the bridgeId again in the query parameters does seem rather redundant.
>     
>
> 
> Scott Griepentrog wrote:
>     So instead of:
>     
>     POST /bridge
>     ...
>     bridgeId: value (optional)
>     
>     You want
>     
>     POST /bridge
>     ...
>     
>     and:
>     
>     POST /bridge/{bridgeid}
>     ...
>     
>     Where the two URI's have the same set of parameters.  Each would end up being it's own separate entry in the documentation.
>     
>
> 
> Paul Belanger wrote:
>     Almost,
>     
>     POST /bridges does not expect or modify the bridgeId, asterisk will generate one and return it. Create bridge using params passed.
>     
>     POST /bridges/{bridgeId} will check to see if bridgeId exists, if not create bridge using using ID and params passed, if bridgeId does exists, update said bridge with new params passed.
>     
>     I see the majority of people using POST /bridges if they are interfacing to asterisk directly, but people writing libraries, using POST /bridges/{bridgeId} more.

I think having bridgeId be an option value to specify in POST /bridges would be fine. It isn't required, and people who are using POST /bridges can transition to specifying the ID when needed without having to muck with much.

Plus, it feels like it fits well in the philosophy of the Robustness Principle: 'be liberal with what you accept, conservative with what you send'


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3278/#review11012
-----------------------------------------------------------


On Feb. 28, 2014, 11:39 a.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3278/
> -----------------------------------------------------------
> 
> (Updated Feb. 28, 2014, 11:39 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23120
>     https://issues.asterisk.org/jira/browse/ASTERISK-23120
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This adds the ability to pass an assigned unique id to bridge creation, and enables ari bridge creation to pass that as a new parameter.
> 
> 
> Diffs
> -----
> 
>   /branches/12/rest-api/api-docs/bridges.json 409051 
>   /branches/12/res/res_stasis.c 409051 
>   /branches/12/res/res_ari_bridges.c 409051 
>   /branches/12/res/parking/parking_bridge.c 409051 
>   /branches/12/res/ari/resource_bridges.c 409051 
>   /branches/12/res/ari/resource_bridges.h 409051 
>   /branches/12/main/bridge_basic.c 409051 
>   /branches/12/main/bridge.c 409051 
>   /branches/12/include/asterisk/stasis_app.h 409051 
>   /branches/12/include/asterisk/bridge_internal.h 409051 
>   /branches/12/include/asterisk/bridge.h 409051 
>   /branches/12/apps/app_confbridge.c 409051 
>   /branches/12/apps/app_bridgewait.c 409051 
>   /branches/12/apps/app_agent_pool.c 409051 
> 
> Diff: https://reviewboard.asterisk.org/r/3278/diff/
> 
> 
> Testing
> -------
> 
> Test https://reviewboard.asterisk.org/r/3277/ now includes a test for this feature, which passes.
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140303/187fcd2f/attachment.html>