*Это вторая часть серии из двух статей от Лонга Ле, архитектора .NET Enterprise и архитектора решений в Computer Sciences Corporation. Часть первую можно прочитать здесь. Лонг – заядлый блогер и серьезный игрок в Modern Warfare 3. Обязательно следите за его разговорами о коде и играх в Twitter @LeLong37 и посетите его блог здесь.*
Twilio предлагает довольно хорошую документацию по разработке с MVC, используя традиционные контроллеры, действия и представления, основанные на их REST API. Однако эта статья будет для тех, кто хочет разрабатывать вокруг Twilio, используя новый Web API MVC.
При работе с платформой Twilio обычно не используются представления (если только вы не вставляете встраиваемый код в разметку ваших представлений). В основном это множество REST-подобных запросов, которые Twilio отправляет вашему приложению, а ваше приложение отвечает XML-сообщениями, чтобы Twilio мог обработать ваш XML-ответ и определить следующий шаг, будь то голосовой запрос и/или SMS.
Итак, приступим. Первое, что мы сделаем, — это подготовим инфраструктуру нашего приложения MVC 4.
В Global.asax.cs добавим расширения путей URI. Это означает, что наши методы Web API будут знать, какой тип контента/данных возвращать из запроса по расширению URL. Например, если у нас есть входящий запрос на коллекцию определенного типа, сопоставленный с http://localhost/api/MyController/MyPost.xml, среда выполнения MVC будет знать, что нужно вернуть мою коллекцию в формате XML, а не JSON (MediaTypeFormatterExtensions.AddUriPathExtensionMapping).
Примечание: Технически нам нужно только UriPathExtensionMapping для XML, однако на случай, если мы решим по-прежнему возвращать JSON-сообщения из наших методов Web API, мы добавим и для JSON. Таким образом, наши методы API смогут возвращать как XML, так и JSON, просто изменив расширение в URL.
Например:
— http://localhost/api/MyController/MyPost.xml, вернет XML-коллекцию
— http://localhost/api/MyController/MyPost.json, вернет JSON-коллекцию
**Обновите и/или добавьте маршрут Web API** (в данном случае я просто заменю существующий, поскольку мне вообще не нужен маршрут по умолчанию), чтобы мы могли поддерживать добавленные нами ранее расширения путей URI (.xml, .json).
Расположение: YourMvc4Project/App_Start/WebApiConfig.cs
Теперь мы можем создать фиктивный пример контроллера Web API для погоды, к которому Twilio будет отправлять запросы.
Метод **GatherZipCode** запросит у звонящего почтовый индекс, для которого требуется информация о погоде.
Метод **RetrieveWeather** фактически прочитает и произнесет текущую погоду звонящему. Очевидно, это пример, и для реальных задач вам, вероятно, потребуется обращаться к реальному сервису погоды, такому как Accuweather.
Я предпочитаю реализовывать это таким образом, потому что в конечном итоге у нас остаются небольшие методы, которые обрабатывают ответы на запросы Twilio, и мы можем использовать объект TwilioResponse для помощи в отправке данных обратно в Twilio. С учетом этого нам не придется беспокоиться о составлении XML-строк в нашем коде. Объект TwilioResponse имеет удобное свойство Element (twilioResponse.Element), которое выполняет удобную сериализацию для нас и предоставляет представление объекта в XML, готовое для отправки в Twilio.
Отлично, как мы можем провести тестирование наших Web API, готовых к работе с Twilio, локально? То есть, давайте проведем тестирование, прежде чем привлекать реальных людей, их телефоны и/или учетные записи Skype.
Вам нужно будет скачать утилиту Curl (http://curl.haxx.se/download).
Запустите ваше приложение и выполните несколько команд для вызова ваших новых методов Web API и убедитесь, что они возвращают правильные XML-сообщения для Twilio. Вы можете сопоставить ваши XML-сообщения с Twilio TwiML Referenence (https://www.twilio.com/docs/api/twiml).
Теперь мы можем сопоставить и сравнить это при просмотре документации по глаголу «Say» в Twilio TwiML, чтобы понять, как использовать глагол «Say» (https://www.twilio.com/docs/api/twiml/say) и получить некоторое представление о том, что мы возвращаем правильные XML-сообщения из наших методов Web API, прежде чем фактически привлекать людей и телефоны.
Следующим шагом, если вы разрабатываете локально и на рабочей станции, которая не доступна публично из Интернета, вы можете использовать Windows Azure Service Bus с его функциями ретрансляции. Шаблон ретрансляции Windows Azure Service Bus практически такой же, как и для служб в облаке, которым необходимо работать со службами, находящимися локально, глубоко внутри инфраструктуры компании, за их брандмауэром.
Вы можете посетить блог Девина http://www.twilio.com/blog/2012/06/relaying-twilio-requests-using-windows-azure.html, чтобы настроить ретрансляцию с помощью Windows Azure Service Bus для разработки Twilio.