Должен ли я завершить действие контроллера в тот момент, когда в запросе обнаружена проблема?

Question

Мне было интересно, как лучше всего подобной ситуации:

У меня есть клиент, который делает POST для регистрации клиента с помощью программы в службе / register в моем веб-приложении.Этот запрос может включать в себя N программ, для которых клиент должен быть зарегистрирован, например:

{
    customer_id: 123,
    program_ids: [ 1, 2, 3 ]
}

Теперь некоторые из этих программ могут быть недоступны для регистрации пользователем, т. Е. Они закрыты.

Мне было интересно, что мне делать с кодом подтверждения запроса моего контроллера на сервере для этой ситуации?

Я полагаю, что мои варианты:

1. Разрешить контроллеру зафиксировать любую действительную программу, с которой клиент может зарегистрироваться в БД, когда он проходит через программы в массиве, а затем ответить клиенту с ошибкой, которая говорит о том, что некоторые вещи работают, но не все.

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

Наконец, если мне нужно перейти с вариантом 2, как мне это сделать?прекратить обработку всего в методе контроллера и просто ответить неверным запросом?

Answer 1

1. Если неверные данные могут быть получены из-за честной ошибки, перейдите к варианту 1: выполнить то, что может быть выполнено, а затем показать сообщение об ошибке.

2. Если недопустимые данные получены в результате злонамеренного поведения (подделка параметров и т. Д.), Перейдите ко второму варианту.Чтобы прекратить обработку всего в методе контроллера, просто вызовите ошибку, которую вы можете решить обработать с помощью rescue_from

Answer 2

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

Лично я думаю, что лучше всего разрешить выполнение любых допустимых действий, а если что-то не получается, отследить это в отдельном массиве (как упомянул Сэм), а затем дать пользователю ленту уведомлений или что-то в этом роде. который говорит: «Эй, я подписал вас на эти программы, но я не мог подписать вас на все из них. Нажмите здесь для получения дополнительной информации», а затем, возможно, есть модальное всплывающее окно, которое сообщит пользователю, какие из них не удалось и для какие причины.

Answer 3

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

С точки зрения технической реализации, для варианта 2 вы, вероятно, захотите рассмотреть такие вещи, как пользовательские проверки и вложенные атрибуты .

Answer 4

Я этого не делал, но скоро буду заниматься мобильной разработкой, и вот как я планирую позаботиться об этом:

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

Затем вы можете вернуть json или все, что вам нужно, чтобы вернуться к этому другому сервису с двумя массивами: один передан, а другой - нет.