Как сделать эту концепцию RESTful?

Question

У меня есть контроллер, занимающийся отправкой SMS-сообщений, и он настроен как ресурс по умолчанию. Теперь бизнес-требования изменились, и мы хотим, чтобы предложить пользователю три различных способа отправки сообщения:

1. Для всех в их списке контактов
2. Для сегментированной части их списка контактов (предопределенные)
3. К индивидуальным контактам, которые они могут выбрать

Кроме того, есть два способа отправить SMS-сообщение: Premium (через sms-шлюз) или стандартный (через SMTP). Таким образом, существует по существу шесть разных способов отправки сообщения (три для премиум-класса, три для стандартных).

Требования утверждают, что эти три варианта выше необходимости быть представлены в формате «мастер-подобный», как три радио выбора кнопки, а затем кнопку, которая отображает соответствующую форму и список представить:

• If вариант 1 (отправить всем), то просто отобразите текстовое поле для отправки SMS
• Если опция 2 (отправить сегменту), то отобразите список сегментов в качестве радиокномов
• Если опция 3 (отправить по электронной почте), то отобразите список с возможностью поиска/сортировки всех контактов с флажками рядом с их именами и на отправке выберите все, отправлять.

Проблема, с которой я сталкиваюсь, заключается в том, как сделать это подходящим соглашениям RESTful, наложенным ресурсом. Каждый из этих случаев использования является технически только одним действием (ну, два, поскольку он будет соответствовать новому/создавать), но похоже, что в действии должно быть слишком много логики в действии, а также довольно беспорядочно (оператор switch или аналогичный).

Есть ли лучший способ сделать это?

Answer 1

Сначала я хотел бы рассмотреть «простейшее, что работает». Различные обработки параметров и настройка нескольких методов доставки выглядят как нечто, что не может быть легко завершено в пару «новых» и «созданных» действий.

Не зная всех деталей, моя первая рекомендация будет заключаться в том, чтобы реализовать такие действия, как "choose_contacts", "send_to_contacts" and "choose_segments", "send_to_segments", которые либо готовят данные для этих случаев использования, либо создают свои собственные шаблоны, либо обрабатывают входящие данные и обрабатывают возможные ошибки. Затем «новое» действие просто отправит обработку в соответствующее действие на основе выбранного параметра, в то время как действие «создать» больше не понадобится (или вы можете повторно использовать его для отправки одного сообщения). Бьюсь об заклад, код для отправки одного сообщения (или набора сообщений) в любом случае находится в модели, поэтому вам просто нужно вызвать его с правильными аргументами, как только вы обработали данные своей формы разумным способом.

Преимущества такого подхода:

1. Он читает более естественно, кто-то, кто будет поддерживать ваш код позже, как это четко дифференцирует возможные варианты;

2. У вас будет больше гибкости при обработке входных параметров и обработке ошибок из разных форм, так как вы будете знать, какое ошибочное состояние отображать как ответ, не перенося дополнительные данные из формы. Сегменты и контакты, вероятно, требуют различной обработки, не так ли?

3. Если вы используете какое-то приложение для управления производительностью (например, NewRelic), вы увидите, имеет ли какое-либо из определенных действий обработки доставки какие-либо проблемы с производительностью намного быстрее, чем в случае общего действия SMSDelivery # create;

У меня была аналогичная ситуация с «приглашением/поиском друзей через процесс загрузки/поиска контактов», и данный подход работал очень хорошо для меня. В целом, REST - отличное соглашение, но попытка сжать много бизнес-логики в CRUD иногда не идеальна и подвержена ошибкам. YMMV, я бы просто предложил логично понять и легко читать, модифицируя существующие соглашения, если вы не чувствуете себя достаточно гибким с ними.