我知道你总是可以给他们一个cookie但你不能这样做,如果他们关闭了cookie,最坏的情况是在这里思考,他们也关闭了javascript.
现在,我理解答案可能是“是的,那就是将要发生的事情”,这就是故事的结局,我可以忍受这一点,但是,对于这个新手,有什么我想念的吗？
答案是您的应用程序(在REST方案中)根本无法跟踪发生的情况.所有状态都由客户端管理,状态转换通过URI导航实现. REST的“状态转移”部分是指客户端导航到新状态的新URI.根据HTTP规范和REST方法,使用GET访问的URI实际上是只读操作.这意味着如果客户端“备份”到某个先前的URI,则“最差”发生的是另一个GET,并且会加载更多数据.
假设客户端执行此操作(使用高度简化的伪HTTP)…
获得//site.com/product/123
这将检索关于产品ID 123的信息(或可能是页面),其可能包括对URI的引用,该URI可用于将该项目发布到用户的购物车中.因此用户决定购买该物品.再次,它过于简单,但：
POST //site.com/shoppingcart/
{productid = 123}
从此返回可能是购物车的表示,或者对添加的项目的引用(可以在购物车URI上使用DELETE再次删除项目),或者其他各种事物(例如更深入的XML描述)购物车内容与其他URI指向购物车项目并返回原始产品).全取决于你.
但“状态”是由客户正在做的任何事情来定义的.它根本不在服务器上跟踪,但您肯定会在数据库中保留一段购物车内容一段时间. (两年后我曾回到一个网站,我的购物车项目仍在那里……)但是由他来跟踪ID.对于您的服务器应用程序,它只是另一条记录,可能是某种过期.
这样您就不需要cookie,而javascript完全依赖于客户端实现.在没有脚本的情况下构建一个体面的REST客户端很困难 – 你可能用XSLT构建一些东西并且只从服务器返回XML,但这可能比任何人都需要的更痛苦.
起点是真正了解REST,然后设计系统,然后构建它.它绝对不适合像大多数其他系统那样(正确或错误)在运行中构建它.
这是一篇优秀的文章,它让你对REST有一个相当“纯粹”的看法,而不会过于抽象而且不会让你陷入困境：
http://www.infoq.com/articles/subbu-allamaraju-rest