[asterisk-dev] ARI feedback

[Paul Belanger]

On 13-10-12 06:13 PM, Paul Belanger wrote:
> Back from Astricon and already hacking our queue app to hook into ARI,
> however I'm curious about how we are going to handle feedback of the
> ARI APIs? How locked down are we on things?
>
> For example, it would be nice when we pass back a UUID (eg: bridging)
> that we named it uuid, not id.  I know it is trivial, but seems to
> help me remember the format better.
>
> Another example, again in bridging is on POST /bridges it expect a
> parameter as 'type' however the API returns 'bridge_type', again, it
> would be nice to have them both the same.  And since 'type' is usually
> a reserved word in languages, bridge_type is better :D
>
> Since I'm typing, what are our chances of using enum fields for things
> like state, bridge_type, technologies, etc. Personally, I'd like keep
> string values out when possible and use an int / enum when I can.
>
> And /sounds, I'd rather see id changed to name, since we are using the
> filename for prompts.  This leaves us the ability to use a UUID if we
> ever added it.
>
> So, ya.  However are we going to handle feedback?  I know the we are
> in beta1, however I get the feeling we are going to see a bunch of
> feedback with the hype of Astricon.
>
> Oh and lastly, can we please do /ari/v1/bridges, please, please,
> please!  Or whatever or version number is. I really, really think we
> need the namespace in the URL.
>
Additionally,

Each ARI object (channel, bridge, sound) also has 'created_at' and 
'updated_at' fields, datetime format (channel already has creationtime). 
  This way we have the ability to track the lifetime of stuff.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger