REST Business Logic и обработка ошибок

Question

Я пытаюсь создать приложение REST, где я пытаюсь скрыть, чтобы скрыть Business Logic от запроса и ответов. У меня есть примеры, которые я не знаю, как обращаться.

Первый пример: у меня есть корзина и продукт х не может быть заказан с продуктом у. Клиент, однако, решил заказать их обоих. Как я могу дать правильное сообщение об ошибке или указать клиенту, что это запрещено. Потому что сообщение об ошибке «x и y не разрешено вместе» похоже на то, что выставляете мне Business Logic.

Структура на месте из-за различных услуг, которые у нас есть. Продукты могут быть повторно использованы, но прием заказов отличается. Например, мы можем предложить прием заказов для транспортных средств, которым нужна другая конфигурация при заказе полотенец. В обоих случаях у вас будет продукт, который имеет имя и цену и, следовательно, может быть повторно использован. Вот почему транспортные средства и ткани не могут быть заказаны вместе и не должны. Чтобы сделать это более удобным для пользователя, будет существовать услуга, которая предоставляет доступные варианты для конкретного заказа. Но должна быть часть, которая проверяет ее и дает правильную ошибку.

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

UPDATE Так решение вопроса для моего первого примера может быть, чтобы создать что-то вроде конечной точки /продукты? Тип = транспортного средства или /произведения/комбинации? Тип = транспортного средства. Это относится к отображению разрешенных продуктов/комбинаций и имеет конечную точку /заказ, чтобы поставить продукты там, где происходит валидация. Эти конечные точки могут стоять сами по себе, но контекст может быть откуда-то еще. Правильно ли я понимаю?

Answer 1

Как уже было сказано, это лишь незначительно связано с REST, я полагаю, что это больше связано со смыслом «разоблачения бизнес-логики» и «безгражданства».

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

Бывают случаи, когда внешняя система должна знать, чтобы иметь возможность направлять пользователя. Не принципиально неправильно раскрывать бизнес-логику, если она неявно не раскрывается, но явно является частью описания интерфейса.

Во втором вопросе о безгражданстве: REST определяет, что сообщение должно быть без гражданства. Это означает, что любой произвольный запрос от клиента должен иметь смысл без контекст любых предыдущих сообщений (включая предыдущие логины, сеансы, что угодно). Каждый запрос стоит сам по себе. Это не означает, что определенные ресурсы не могут сохранять собственное состояние. У корзины покупок на бэкэнде действительно есть состояние, все в порядке.

Или сказал по-другому: может ли следующий запрос попасть на другой сервер и все еще быть успешным? И я имею в виду без репликации сеанса, распределенного кеша или другой магии. Если да, сообщение не имеет гражданства. Если вам нужны «липкие» сеансы или такие вещи, то нет, вы не являетесь апатридом.

Answer 2

Я думаю, что ваши вопросы не полностью связаны с самим REST, но я постараюсь ответить им в любом случае. Может быть, вы можете дать более подробную информацию о том, что мешает вам читать мои ответы.

Я не совсем уверен, как первый вопрос связан с REST, потому что я чувствую, что это касается формулировки. Вопрос для меня был бы следующим: почему не разрешается заказывать оба этих продукта вместе? Таким образом, вы не можете не попасть в одну и ту же корзину покупок? Это было бы не очень удобно, поэтому лучше всего было бы это позволить. Если вы не можете изменить то, что оба одновременно не разрешены, я бы просто «седел» все элементы, которые не разрешены вместе с продуктом X, если он уже находится в корзине покупок.

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

К вашему второму вопросу: в большинстве интернет-магазинов у вас обычно есть состояние, которое либо отображается на счет, сеанс, либо через файлы cookie. Если вы действительно хотите иметь API без состояния здесь с REST, вы можете работать с идентификаторами заказа. Они могут быть переданы каждому запросу. Конечно, сам порядок имеет состояние. Но запросов нет.

Примечание: REST не означает многого. У вас в принципе нет состояния для каждого запроса и есть вся необходимая информация в URL-адресе.

Возможно, это уже немного помогает.