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

[Matt Jordan]

> On Feb. 28, 2014, 3:09 p.m., Paul Belanger wrote:
> > Woah, nice. What about the ability to do PUT /bridges/a1b2c3, creating the bridge if it doesn't exists.
> 
> Paul Belanger wrote:
>     Actually, the more I think about this. The more I can see having PUT and dropping POST, like we do in deviceStates and mailboxes.  Perhaps we should talk about this on app-dev-list, since I'd likely control the UUID from my library then have asterisk do it.

I disagree, for a couple of reasons.

(1) Dropping an operation seems like an unnecessary breaking change at this point. If we're going to make a breaking change, we should do so because we feel like it is absolutely necessary - I think I'd want some very concrete reasons before advocating that.

(2) With the deviceStates and mailboxes resources, the PUT operation changes the state of the resource being affected. Yes, it creates it as well if it doesn't exist - but the fundamental operation is storing something in relation to a resource (state, number of messages, etc.). A bridges resource, on the other hand, doesn't have a user defined state in the same fashion. What's more, the purpose of the operation is to just create the bridge, not to store anything in relation to it, or change its state.

Keep in mind the definitions of POST and PUT from RFC 2616 (9.5/9.6):

"The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line."

"The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI."

A POST makes more sense when the operation simply creates a new resource; a PUT makes more sense when you are storing something in relation to a resource. In this case, POST seems a better choice than PUT.


- Matt


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


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/20140301/c9683625/attachment-0001.html>