Application.validateApplication should not require all callback URLs to be defined

[euskode]

If you just set the SMS Status Callback URL for an application and nothing else, the isValidApp method insists that other "required" properties be present in the application object, which should not be the case, especially if all you want to do is use Twilio for SMS sending.

[singlow]

I assume you are talking about Application.validateApplication(appInfo)?

I notice that that is not just a validation function - it also sets some defaults - seems like something that should be separated.

I don't see any other use of that function outside of the register method. We could of course do a check for either SMS URI or Voice URI. Is there a big advantage to doing this over providing a Voice URI that returns something, even if it is a simple hangup?

What is Twilio's behavior when a voice call is made to a number with no Voice callback?

[bminer]

Agreed. This probably needs some work. It was just easier to write the rest of the library with the assumption that the Application Object had a VoiceURL, etc. already defined. Anyone have any thoughts on how this should be changed?

Also, I will accept pull requests. Thanks!

[euskode]

Yeah, I am talking about Application.validateApplication; I referenced the old method name since I was debugging 0.3.1 locally. I am actually not using any middleware functionality anymore, as it does not appear to work with restify properly, so I just have my own entry point for the SMS status callback.

I thought it was odd that I was required to have valid values for all of the URL values (even voice ones), when all I was trying to do was send an SMS, and listen in on the status callback, but this may not be an issue after all.

One way to handle this might be to maintain a property of whether an application has been verified for a certain use, and perform validation on the application once this functionality is accessed, thus ensuring that if SMS is all that is being used, having no voice-related parameters does not present a problem.

[bminer]

@euskode - I agree. I'll leave this issue open, but I probably won't have much time to work on this in the near future. I will accept pull requests, though. :)

The obvious workaround is to just use "fake" callback URLs for the your VoiceURL, etc. just to make node-twilio-api happy.