#ruby-on-rails #shipping
#ruby-on-rails #Доставка
Вопрос:
Я запрашиваю тарифы доставки из внешнего API и получаю такие результаты, как:
ground : '$1'
express : '$5'
Затем я показываю эти параметры пользователю, где они выбирают один. В идеале они должны отправлять идентификатор, представляющий, какой вариант они выбрали, и я бы искал соответствующий вариант, но для его поиска мне нужно иметь сохраненный список опций. Я могу сохранить список опций в своей базе данных, но мне нужно будет обновить его, если они вернутся и изменят свой адрес или товары в своей корзине.
Это означает, что я, по сути, кэширую и повторно кэширую параметры доставки, что кажется большим количеством накладных расходов для того, что кажется относительно простой задачей.
Есть ли более простой способ сделать это, который я упускаю из виду?
Комментарии:
1. Почему бы не сохранить список параметров в
$_SESSION? В любом случае это не кажется мне таким уж накладным расходом.2. @Jordan:
$_SESSION? Я думаю, вы думаете о PHP. Это Ruby. Вы бы использовалиsession, если бы это было так.3. Ха-ха, спасибо, Райан. Определенно разнесено на этом.
4. В любом случае, я использую rails, но это более общий вопрос дизайна 🙂 Я иду по этому пути, хотя я сохраняю его в
ordersтаблице, но на него ссылаются в сеансе.
Ответ №1:
Зачем хранить это? Динамически генерируйте форму / раскрывающийся список на основе ответа от API и устанавливайте значение раскрывающихся списков так, чтобы оно содержало не идентификатор, а курс доллара. Тогда параметр, который вы получаете обратно в свой контроллер, представляет собой сумму в долларах из API и вставляется в форму, а не идентификатор записи.
Предполагая, что стоимость доставки время от времени меняется, хранить его в любом случае нет смысла. Как правило, это цель API, поэтому вы всегда можете просто посмотреть его, когда это необходимо. С другой стороны, маловероятно, что стоимость доставки для данного заказа изменится в течение сеанса пользователя.
Чтобы отразить ваши комментарии ниже, вы могли бы кэшировать скорость доставки, общий вес заказа и адрес назначения на момент заказа. Затем повторно запрашивайте новую стоимость доставки только в том случае, если изменится вес, товары в заказе или адрес назначения.
Комментарии:
1. Проблема заключается в том, что кто-то не может манипулировать формой и отправлять стоимость доставки в размере 0 долларов США или — 100 долларов США. Мне нужно сравнить это с чем-то, верно?
2. Ах, мне жаль, что я пропустил это — конечно, вы правы. Вы можете заполнить раскрывающийся список значением типа доставки вместо цены (т. Е. 1 = стандартная доставка, 2 = экспресс-доставка и т. Д.), А Затем рассчитать окончательную цену при оформлении заказа. Храните типы доставки, которые вы поддерживаете, в своей базе данных. Вы можете вставить цену в раскрывающийся список с помощью вызова API, а затем просто выполнить 2-й вызов API во время окончательного расчета, я полагаю. Вы можете кэшировать его, чтобы попытаться сэкономить на вызовах API, но вам нужно будет установить время истечения срока действия кэша, чтобы максимально точно определить стоимость доставки.
3. Сохраняйте окончательную указанную стоимость доставки в самом заказе, чтобы она не отличалась от того, что вы сообщили клиенту при оформлении заказа, и когда деньги действительно поступят с вашего счета. Если вы обеспокоены ростом стоимости доставки (и потерей денег) между заказом и фактическим отправлением, добавьте небольшую наценку (1-2%) к стоимости доставки каждого заказа, чтобы покрыть такие проблемы, или просто съешьте стоимость.
4. По сути, это то решение, к которому я пришел. Таким образом, то, что видит клиент, и то, что он платит, обязательно будут одинаковыми, и они не смогут подделать данные. Я кэширую указанные тарифы доставки вместе с весом заказа и адресом доставки. Если вес или адрес меняются, тарифы запрашиваются повторно, в противном случае используется кэш. Если вы хотите обновить свой ответ, я отмечу его, если у кого-то еще нет блестящей идеи 🙂