我所理解的是根据REST概念
a)服务器无法维护会话以提高可扩展性等原因
b)客户端的每个请求都应该是独立的
现在,我真的很困惑如何实现这一点.假设我们采用简单的购物车应用程序.
步骤1)客户端发送认证请求,服务器认证,服务器响应OK.
步骤2)客户端向购物车发送添加项目的请求.服务器响应OK.
步骤3)客户端发送另一个请求,将第2项添加到购物卡.服务器响应OK.
通常,在通常的Web应用程序中,在服务器上的步骤1中创建会话,从那时开始,与该客户端相关的所有请求将自动与相同的会话相关联,并且我们将会话状态(在这种情况下为购物车)存储在会话对象,并检索/更新客户端的后续请求.
现在,在上述情况下：
1)如果服务器上没有会话维护,我们如何在步骤2和3中验证和授权客户端？
客户需要每个请求发送一些附加信息？
3)如何在步骤3中检索客户特定的购物车？
4)客户端是否需要在步骤3中再次发送步骤2中由服务器创建/返回的购物车？
显然,这是最简单的用例,因此每个开发RESTful Web服务的人都必须设计他们的应用来处理这个问题.使用RESTLet在RESTful Web服务中处理会话管理,身份验证,授权的最佳和最常用的方法是什么？如果我们必须在客户端数据的服务器端维护缓存,那么我们代表服务器维护会话有什么不同？
提前致谢,
深
解决方法
1) how do we authenticate and authorize Client in Step 2 and 3 if
there is no session maintained on the server ?2) does client need to send some additional information with each
request ?
是.您必须在每个请求中发送身份验证/授权数据.这将阻止服务器“记住”你是谁(即无状态服务器,没有会话)
3) How do we retrieve the client specific Shopping Cart in Step 3 ?
我们来问一个不同的问题：如果服务器重新启动会发生什么？您是否希望所有购物车数据丢失？可能不会.你应该把它存放在一个重新启动的地方.应用持久存储.可能在服务器或客户端…
…现在,如果您的客户端重启？您可以选择使用POST请求(用户添加第一个项目)为该用户创建购物车资源,或者在客户端登录时(浪费)创建购物车资源.然后使用PUT / DELETE继续更新购物车,并使用GET进行读取.
应该在数据库？可能,取决于这是怎么想要的.如果它必须坚持下去,这是一个很好的地方来保持它,以便它可以在重新启动后生存.
那么如何接收客户特定的购物车？那么你只需要发送GET资源的请求！而已！第一个POST将在适当的URL创建一个资源,然后可以使用它.
稳定的网络服务还具有安静的网址,这是设计的关键部分.
4) Does the client need to send it’s Shopping Cart that was
created/returned by server in Step 2 again in Step 3 ?
不,如上所述.但是,如果您在客户端使用cookies或LocalStorage或其他信息,那么也许您会这样做.
ObvIoUsly,this is the simplest use case and so every one developing
RESTful web services must be designing their app to handle this. What
is the best and most common way to handle session management,
authentication,authorization in RESTful web services using RESTLet ?
是.这很简单,但是需要一段时间来思考“资源”而不是“服务”.在安静的设计中,一切都是(或可以)一个资源,包括交易,购物车等,
但是,授权/认证是http请求数据包的一部分,并随每个请求一起发送.我建议你阅读那些.
If we have to maintain cache on server side with the client’s data
then how is this different from server maintaining sessions on our
behalf ?
巨大差距！您是否为高效缓存或维持会话？如果系统重新启动,您的系统将在空缓存上无缝工作？如果是,您正在缓存您正在维持状态的其他表现.
我强烈建议您阅读Richardson& Ruby来阐述上述概念,并且深入了解如何设计安静的服务…它需要一些习惯.
