[asterisk-dev] [Code Review] 2940: ARI: User better nicknames for ARI operations

Paul Belanger reviewboard at asterisk.org
Fri Oct 18 17:51:04 CDT 2013


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


Cool, I ran into the same issue while doing python-ari.  Below are some suggestions / recommendation on how I named things.

But in general, I think we should use something like the following

get (single)
create (POST)
delete (DELETE)
list (multiple)

add (toggle)
remove (toggle)

addSomething (toggle)
removeSomething (toggle)

Thoughts?




/branches/12/rest-api/api-docs/applications.json
<https://reviewboard.asterisk.org/r/2940/#comment19184>

    what about list?



/branches/12/rest-api/api-docs/bridges.json
<https://reviewboard.asterisk.org/r/2940/#comment19185>

    same comment... I'll skip the rest.



/branches/12/rest-api/api-docs/bridges.json
<https://reviewboard.asterisk.org/r/2940/#comment19186>

    I prefer delete to destory, seems less violent.



/branches/12/rest-api/api-docs/bridges.json
<https://reviewboard.asterisk.org/r/2940/#comment19187>

    This might be for another review, but what about just addMusic?
    
    moh is not very description and add to the fact we already have a hold function.



/branches/12/rest-api/api-docs/bridges.json
<https://reviewboard.asterisk.org/r/2940/#comment19188>

    removeMusic



/branches/12/rest-api/api-docs/channels.json
<https://reviewboard.asterisk.org/r/2940/#comment19189>

    would rather keep this as delete to keep things consistent.  Otherwise, we should move this to the /hangup action.



/branches/12/rest-api/api-docs/channels.json
<https://reviewboard.asterisk.org/r/2940/#comment19191>

    We see to flip flop between hold / unhold and addChannel / removeChannel.  What about just using add / remove everywhere?
    
    
    addHold / removeHold seems more consistent 



/branches/12/rest-api/api-docs/channels.json
<https://reviewboard.asterisk.org/r/2940/#comment19190>

    same comment as above


- Paul Belanger


On Oct. 18, 2013, 9:09 p.m., David Lee wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2940/
> -----------------------------------------------------------
> 
> (Updated Oct. 18, 2013, 9:09 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> While working on building client libraries from the Swagger API, I
> noticed a problem with the nicknames.
> 
>     channel.deleteChannel()
>     channel.answerChannel()
>     channel.muteChannel()
> 
> Etc. We put the object name in the nickname (since we were generating C
> code), but it makes OO generators redundant.
> 
> This patch makes the nicknames more OO friendly. This resulted in a lot
> of name changing within the res_ari_*.so modules, but not much else.
> 
> There were a couple of other fixed I made in the process.
> 
>  * When reversible operations (POST /hold, POST /unhold) were made more
>    RESTful (POST /hold, DELETE /unhold), the path for the second operation
>    was left in the API declaration. This worked, but really the two
>    operations should have been on the same API.
>  * The POST /unmute operation had still not been REST-ified.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/ari/resource_applications.h 401260 
>   /branches/12/res/ari/resource_applications.c 401260 
>   /branches/12/res/ari/resource_asterisk.h 401260 
>   /branches/12/res/ari/resource_asterisk.c 401260 
>   /branches/12/res/ari/resource_bridges.h 401260 
>   /branches/12/res/ari/resource_bridges.c 401260 
>   /branches/12/res/ari/resource_channels.h 401260 
>   /branches/12/res/ari/resource_channels.c 401260 
>   /branches/12/res/ari/resource_endpoints.h 401260 
>   /branches/12/res/ari/resource_endpoints.c 401260 
>   /branches/12/res/ari/resource_events.h 401260 
>   /branches/12/res/ari/resource_events.c 401260 
>   /branches/12/res/ari/resource_playback.h 401260 
>   /branches/12/res/ari/resource_playback.c 401260 
>   /branches/12/res/ari/resource_recordings.h 401260 
>   /branches/12/res/ari/resource_recordings.c 401260 
>   /branches/12/res/ari/resource_sounds.h 401260 
>   /branches/12/res/ari/resource_sounds.c 401260 
>   /branches/12/res/res_ari_applications.c 401260 
>   /branches/12/res/res_ari_asterisk.c 401260 
>   /branches/12/res/res_ari_bridges.c 401260 
>   /branches/12/res/res_ari_channels.c 401260 
>   /branches/12/res/res_ari_endpoints.c 401260 
>   /branches/12/res/res_ari_events.c 401260 
>   /branches/12/res/res_ari_playback.c 401260 
>   /branches/12/res/res_ari_recordings.c 401260 
>   /branches/12/res/res_ari_sounds.c 401260 
>   /branches/12/rest-api-templates/ari_resource.c.mustache 401260 
>   /branches/12/rest-api-templates/ari_resource.h.mustache 401260 
>   /branches/12/rest-api-templates/asterisk_processor.py 401260 
>   /branches/12/rest-api-templates/res_ari_resource.c.mustache 401260 
>   /branches/12/rest-api-templates/rest_handler.mustache 401260 
>   /branches/12/rest-api-templates/swagger_model.py 401260 
>   /branches/12/rest-api/api-docs/applications.json 401260 
>   /branches/12/rest-api/api-docs/asterisk.json 401260 
>   /branches/12/rest-api/api-docs/bridges.json 401260 
>   /branches/12/rest-api/api-docs/channels.json 401260 
>   /branches/12/rest-api/api-docs/endpoints.json 401260 
>   /branches/12/rest-api/api-docs/playback.json 401260 
>   /branches/12/rest-api/api-docs/recordings.json 401260 
>   /branches/12/rest-api/api-docs/sounds.json 401260 
> 
> Diff: https://reviewboard.asterisk.org/r/2940/diff/
> 
> 
> Testing
> -------
> 
> Hit each ARI resource to ensure it still responded.
> 
> 
> Thanks,
> 
> David Lee
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131018/4508340a/attachment-0001.html>


More information about the asterisk-dev mailing list