Loading Profile...
Suggestions to improve the API
Good Morning All,
I used the Twilio service to create a Twitter bot that would call folks when it received a direct message. It would then post a URL to to the recording as an update. It was fun to write, and I have some suggestions after doing so that would have made it easier:
1. I really don't understand why the RESTful API used to initiate a new calls (/2008-08-01/Accounts/{YourAccountSid}/Calls) needs a URL pointing to the TwiML. It would be easier to use and more efficient if the TwiML could be included when making that request. I wouldn't have to maintain another file either, making my document management easier.
2. It would have been nice if I was able to pass some data when initiating the call and have this returned to me when the callback was invoked. (This may be possible, but I wasn't able to figure it out if it is. I saw that notification instance resources contain request variables, but I wasn't sure if this could be set by my client when initiating the call. Because of this, I wasn't able to, for example, say in the Twitter bot's update who recorded a message. To do this, I would have to pass that when starting the call and get it back when handling the callback from Twilio.)
This is the conversation that I ended up with:
1. Client C calls /2008-08-01/Accounts/{YourAccountSid}/Calls on the Twilio server S passing in URL U to a TwiML document X
2. S requests U and parses out the callback URL B from X
3. S makes a phone call
4. S sends a message to B (the callback)
5. B updates Twitter status by calling that service's API using the the RecordingUrl (given to B from S)
(If I am right that notifications could have been used to pass arbitrary data, the number of request/response messages needed in this conversation would have been increased by approx. 50% - 100%.)
If the TwiML document X could have been passed instead of U, the number of requests/responses would have been reduced to this:
1. C calls /2008-08-01/Accounts/{YourAccountSid}/Calls on S passing X (and Caller and Called as before)
2. S makes a phone call
3. S sends a message to B
4. B updates twitter
Ideally, this is what I would have been able to do:
1. C calls /2008-08-01/Accounts/{YourAccountSid}/Calls on S passing X and arbitrary data D
2. S makes phone call
3. S sends a message to B including D (and RecodingUrl as before)
4. B updates twitter using RecordingUrl and D
Having said all this, I think that Twilio is a great service, and I'm excited to see what the future holds for it.
--
Regards,
Travis Spencer
I used the Twilio service to create a Twitter bot that would call folks when it received a direct message. It would then post a URL to to the recording as an update. It was fun to write, and I have some suggestions after doing so that would have made it easier:
1. I really don't understand why the RESTful API used to initiate a new calls (/2008-08-01/Accounts/{YourAccountSid}/Calls) needs a URL pointing to the TwiML. It would be easier to use and more efficient if the TwiML could be included when making that request. I wouldn't have to maintain another file either, making my document management easier.
2. It would have been nice if I was able to pass some data when initiating the call and have this returned to me when the callback was invoked. (This may be possible, but I wasn't able to figure it out if it is. I saw that notification instance resources contain request variables, but I wasn't sure if this could be set by my client when initiating the call. Because of this, I wasn't able to, for example, say in the Twitter bot's update who recorded a message. To do this, I would have to pass that when starting the call and get it back when handling the callback from Twilio.)
This is the conversation that I ended up with:
1. Client C calls /2008-08-01/Accounts/{YourAccountSid}/Calls on the Twilio server S passing in URL U to a TwiML document X
2. S requests U and parses out the callback URL B from X
3. S makes a phone call
4. S sends a message to B (the callback)
5. B updates Twitter status by calling that service's API using the the RecordingUrl (given to B from S)
(If I am right that notifications could have been used to pass arbitrary data, the number of request/response messages needed in this conversation would have been increased by approx. 50% - 100%.)
If the TwiML document X could have been passed instead of U, the number of requests/responses would have been reduced to this:
1. C calls /2008-08-01/Accounts/{YourAccountSid}/Calls on S passing X (and Caller and Called as before)
2. S makes a phone call
3. S sends a message to B
4. B updates twitter
Ideally, this is what I would have been able to do:
1. C calls /2008-08-01/Accounts/{YourAccountSid}/Calls on S passing X and arbitrary data D
2. S makes phone call
3. S sends a message to B including D (and RecodingUrl as before)
4. B updates twitter using RecordingUrl and D
Having said all this, I think that Twilio is a great service, and I'm excited to see what the future holds for it.
--
Regards,
Travis Spencer
I’m indifferent
1
person likes this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Hi Travis,
Thanks for the feedback, we're always looking to hear new ideas for Twilio.
1. I really don't understand why the RESTful API used to initiate a new calls (/2008-08-01/Accounts/{YourAccountSid}/Calls) needs a URL pointing to the TwiML.
We've given some thought to implementing outbound calls the way you describe, and in the short term, decided for the (arguably) simpler approach that gives parity with incoming calls. We're definitely open to other methods, including what you describe, as alternate ways of making calls that might be simpler for some use cases.
> 2. It would have been nice if I was able to pass some data when initiating the call and have this returned to me when the callback was invoked.
I believe I understand the issue... many people pass application data via URL query string, which would then get passed back to your application. For example, if you initiated a call with URL:
http://myserver.com/handler.php?twitt...
Then when the callback is initiated, you could find the twitterId in your GET variables. You can also pass that URL along to subsequent URLs, but if you find that you're passing the same data everywhere, you can just set a cookie! Just like a web browser, we'll return any cookies in subsequent requests during the call.
Let us know if these answer your questions, or if any other questions arise.
Thanks for the feedback!
-jeff -
Inappropriate?Hi Jeff,
Thanks for the response. I'm satisfied with those answers, but I'm not sure you completely groked the need to pass arbitrary data in/out of the service when initiating calls. You can check out my blog post on this issue and my experience using the Twilio service at http://travisspencer.com/blog/2008/12....
Thanks,
Travis Spencer -
Inappropriate?Hi Travis,
Thanks for sending the blog post, very detailed and very well thought out.
Let me answer a couple questions raised in the post:
1. Sending opaque data, such as the name of the Twitter user, through the chain. This is entirely possible. In your Tweetbot, Tweetybot.py, you presumably have the name of the user in a variable, let's say TWITTER_ID. Now, instead of setting your call handler to a static XML file, use a programming language to generate the TwiML, and use a URL like:
http://web.cecs.pdx.edu/~tspencer/twi...
Then in that script, pass the value along to the Recording handler:
<Record action="http://web.cecs.pdx.edu/~tspencer/playback.cgi?TwitterID={Request.TwitterID}" maxLength="55"/>
(Apologies, I don't know the exact syntax for Python)
Then in the playback.cgi script, you'll have original TwitterId ready for use in your tweet!
2. HTTPS! We entirely support HTTPS, and in fact, recommend it.
3. The RecordingUrl given to you, and which you republish on Twitter, does include your AccountSid, but that is like a username and is considered public. Your AuthToken, which should be kept secret, is not necessary or a part of that URL, so your credentials are entirely secure through the process here.
Let me know if we can answer any other questions, but looks like a great idea and implementation.
Cheers,
-jeff
EMPLOYEE
