Возможно недопонимание ещё и в том, что я чётко разграничиваю понятия COOKIE и SESSION. Первое — файлы на стороне клиента, инициализированные сервером, значения из которых можно посылать серверному скрипту для манипуляций (сравнения значений с данными из БД и т.п.), в данном случае сервер не обязан хранить соответствия, все данные есть у клиента. Второе — файлы в temp директории сервера, SID посылается клиенту, чтобы он его потом вернул, тем самым поддерживая сеанс. Сессию можно и не инициализировать. Сессия может не использовать cookie.
Желания противопоставить нет, это всего лишь другой метод работы.
Кука находится у клиента, $_SESSION на сервере. Но по сути полумера, если отталкиваться от концепции REST предложенной Роем Филдингом. Здесь про это написано: Representational State Transfer (http://en.wikipedia.org/wiki/REST). Ко всему прочему это только один из принципов REST, есть и ряд других.
$_SESSION находится на сервере. Возможно использование куков не в полной мере соответствует изначальному REST, т.к. сами куки появились как надстройка над протоколом.
PHPSESSID, само название говорит о причастности к серверу. $_SESSION находится на сервере. «Настоящее RESTful PHP приложение должно быть полностью независимо, все запросы должны содержать достаточно информации чтобы на них можно было отреагировать без дополнительных усилий со стороны сервера.» При использовании cookie запрос становится самодостаточным.
Это даже плюс, не нужно физически удалять файл заданный как URI ресурса для метода HTTP DELETE. В PHP происходит эмуляция данного метода и решение о нужном действии принимает скрипт. К тому же использование человеко-понятных-урлов вида /tech/news/, делает это вполне логичным.
«A truly RESTful PHP application should be entirely stateless» — Правильное RESTful PHP приложение должно быть свободно от сохранения состояния (клиент/сервер). Массив $_SESSION не подпадает под эту идеологию.
Это для примера, если нужна глобальность — пожалуйста, её вред моё личное убеждение, я бы обошёлся свойствами объектов и т.п. В примере показано как обойти ограничение в отсутствии PUT, DELETE и прочих методов. Вполне логично показать это на примере, который уже есть: $_POST или $_GET. Назвать переменную можно как угодно: $put_method_data, $this->put и т.п. В примере показано создание $_PUT для простоты восприятия.
Вот описание www.inattack.ru/article/572.html
Вот пример eyeonsecurity.org/advisories/flash-demo/demo1.html если подождать выдаёт алерты
Желания противопоставить нет, это всего лишь другой метод работы.
В споре рождается истина…
Глобальные переменные сложно отследить в развитом приложении, их можно подменить если используется extract(). Этого не достаточно?