Ведение данных POST между взаимодействиями Twilio

Мне интересно, как лучше всего сохранить информацию, собранную в результате взаимодействия с Twilio.

Допустим, я собираю PIN-код на первом этапе. Затем номер ФАКСА на втором этапе.

Могу ли я сказать Twilio отправить проверенные данные обратно в мое приложение при следующем запросе? Поэтому при запросе ФАКСА также отправляется и анализируется PIN-код.

В противном случае я мог бы использовать сеанс или отправить информацию обратно в строке запроса / GET.

Было бы здорово услышать, как другие справились с этим.

N.B. Я видел это, которое поддерживает идею использования GET. Тем не менее, я хотел бы попытаться избежать этого метода, если это возможно.


c# twilio mv
person atoms    schedule 23.10.2017    source источник
comment
два общих предложения. 1. Веб-сервисы REST - это состояния. 2. Короче говоря, в REST: POST == insert, PUT == update (я не знаю twilio, предполагаю, что он правильно разработан)   -  person Jacek Cz    schedule 23.10.2017
comment
спасибо знаю об этом. Мне интересно, могу ли я сказать Twilio включить некоторые данные в ответ TwiML. В противном случае я буду использовать сеансы или ПОЛУЧИТЬ. Отсюда мой вопрос о том, что лучше всего подходит / возможно. Twilio также отправляет файлы cookie с запросами. Что касается флага закрытия, я ищу; факты, ссылки или конкретный опыт. !!   -  person atoms    schedule 23.10.2017

Ответы (1)


arrow_upward
1
arrow_downward

Проповедник разработчиков Twilio здесь.

Вы не можете напрямую указать Twilio сохранить состояние вашего приложения и отправить его как часть последующих запросов POST.

Вы упомянули некоторые альтернативы, такие как использование файлов cookie, поддерживаемых Twilio, для хранения данных или добавление данных в строку запроса следующего URL-адреса.

Я думаю, что лично я бы чувствовал себя в большей безопасности, если бы хранил данные на своей стороне. Я бы собирал данные, которые вам нужны, из вызова CallSid в какой-то базе данных, и после того, как вы собрали все необходимые данные, введите их в свою базу данных для записи, которую вы создаете. Таким образом, вы всегда сохраняете полученные данные, вы можете использовать частично завершенные вызовы, чтобы определить, есть ли конкретный этап возврата, и даже создавать новые вызовы для завершения сбора данных вместо того, чтобы начинать с нуля с вызывающим абонентом каждый раз, когда он делает попытка.

Однако это всего лишь варианты, и ваша собственная архитектура приложения должна указывать на ваш выбор, какой из них лучше.

person philnash    schedule 24.10.2017
comment
Отличный ответ, большое спасибо, Фил! Некоторые действительно хорошие преимущества перед inproc или подобными. Ваше здоровье! - person atoms; 24.10.2017
comment
Не беспокойтесь, надеюсь, ваше приложение работает хорошо! - person philnash; 24.10.2017