bazilekolyan2288, раз ты используешь cookie, то любые изменения подразумевают полную замену значения. Никак иначе. И не важно корзина это или что-то другое.

kolyan22881. Получаю Get параметр id товара;
Добавлять товары в корзину следует POST запросом т.к. GET запрос не должен иметь побочных эффектов.

kolyan22884. Записываю все данные в массив;
Хранения цены в cookie плохая идея т.к. её значение несложно исправить или подделать.

не слушай его... человек говрит общие фразы не понимая их смысл.


ГЕТ запрос, по умолчанию кешируеться. тоесть если у тебя заказ первого товара 1, и ответ попадёт в кеш, то для следующей покупки, в теории, при покупке сначала товаров 2, 3, ...100, а потом первого, ответ может вернуться из кеша - и в корзине твоей в куках получиться купленый товар только первый!!!

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

(вообще конечно же ты можешь возразить, а какже пагинация на сайте новостей...там всегда любая страница новостей выдаёт немного другой список новостей(новости пополняються) - ответ, управление кешем, последняя дата модификации/етег в хедерах)...ты первый раз делаешь, делай проще!)

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

насчёт защиты от третьих лиц...ну тут шттпс надо а не куки или не куки.

другое дело, что любые данные от клиента надо проверять, дабы небыло сбоя в работе.

хранил бы корзину на сервере, не надо валидировать...а то вот пришла корзина, при валидации оказалось что вписан товар с несуществующим айди...и что пользователю вывести? а ведь может ошибка на сайте... при заказе товара 100, данные на сервер пошли 1000(один нолик от верстальщика остался лишний).

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

bazilealex564657498765453гет запрос должен отдавать всегда одно и тоже на один и тот же запрос
alex564657498765453(вообще конечно же ты можешь возразить, а какже пагинация на сайте новостей...там всегда любая страница новостей выдаёт немного другой список новостей(новости пополняються) - ответ, управление кешем, последняя дата модификации/етег в хедерах
Сам придумал про "гет запрос должен" и сразу же себя опровергнул. Молодец.

alex564657498765453хранить корзину в куках - вполне нормально, с точки зрения сервера, ему всеравно кто и как будет подделывать корзину. от этого торговая логика не изменится. пришол заказ 10 коробок трусов, ну счёт на платёжную систему будет выставлен на 10 коробок трусов, и побую что человек подделал корзину.
Я говорил только о хранении цены, а не корзины.

учи мат часть


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

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются идемпотентными

последнее слово, означает - но один и тот же запрос должен быть один и тот же ответ, при условии что содержимое не изменилось по иным причинам.

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

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

хотя если ссылка по типу /tovar50/col30/addcart/sess_key_fjlkdsjflkdsjfldsjflksdjflkds
и последнее генерируеться уникально и однорозовоиспользуеться...то можно и гетом.
Читаем строку - или гет запрос может начать какой либо процесс, и ответ - состаяние этого процесса. в данном случае процес, заталкивание выбранной части покупки, идентифицированную сессионым ключом, который только для этой покупки, и только один раз, в корзину... но это уже маразм для интернет магазина. подобное нужно если в магазине выбираеться не готовый товар, а через кучу кликов конструируеться заказ. например пица из запчастей.
собственно тогда добавление сконтруированой пицы мало чем отличаеться к продвижению заказа к исполнению(корзины). и вполне нормально использовать гет, но надо добавить чтото уникальное в ссылку, что б не нарушать феншуй.

bazile,

ты же сам по сути это же говорил, только не понимая что говоришь... я про фразу "без побочного эффекта"

побочных ефектов может быть куча, главное чтоб целевой запрос не изменялся изза самого обращения. хотя это очень скользкий момент. если часть описания товара, являеться его рейтинг=число просмотров, то получаем что любой просмотр товара меняет само описание товара.это на многих сайтах встречаеться.

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

гет бытсрее поста /пута
гет кешируеться, пут нет(априори его не закеширует никто), пост в теории можно закешировать... но на деле... лишено смысла в большинстве случаев.

исходя из это и строить логику. и пренебрегать, тем чем готов пренебречь...
например для случая описания товара с числом просмотров, что вася смотря 1000м товар, увидит описание из кеша с числом просмотра 700. устраивает вперёд, нет, начинаем играться хедарами управления кешированием, или исчём другой путь.