On Mon, Oct 21, 2013 at 9:15 AM, Joshua Colp <jcolp at digium.com> wrote: > Paul Belanger wrote: >> >> On to the next topic :D >> >> So, Josh has a patch up on reviewboard[1] that adds indication support >> to /channels. After looking at the patch, it looks like we 2 basic >> ways of controlling a channel with /channel/:id >> >> Either you can use: >> >> /answer >> /hold >> >> or you can use: >> >> /indicate?name=busy >> >> For the sake consistency I'd like to see us pick one. I can go either >> way, but the more I think about it >> >> /indicate?name=answer >> /indicate?name=hold >> /indicate?name=busy >> >> would give us a cleaner API for channels. >> >> Thoughts? > > > I agree that the hold stuff should go into indicate but I'm torn on moving > answer there because having it separate makes the API more approachable by > non-telephony developers. They probably don't know about indications and may > not even ever need to. They do know what answer is though right off the bat. > > (That's personal preference, as I favor a balance of > clean/approachable/logical when it comes to API design). > Fair enough, then I would propose dropping /indications and just having /busy. /answer, /hold routes and move on. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger