从技术角度来看,REST看起来是正确的方式,因为它利用了http的全部功能,并导致高度可扩展的应用程序.但这需要付出代价.在许多情况下,复杂的GUI将需要客户端上的JavaScript应用程序.如果应在客户端维护状态,则必须保持在同一页面并仅重新加载部分.或者你必须使用隐藏的iframe技巧.有时在服务器上有像购物车一样的伪资源,以启用RESTful设计.你必须保持多步对话的中间状态等等……
如果我环顾四周,很少有RESTful GUI Web应用程序.这是因为历史原因还是RESTful设计在常见情况下无效？
解决方法
If I look around there are very few
RESTful GUI webapplications. Is this
because of historical reasons or is a
RESTful design unproductive in common
scenarios?
我的回答是主观的,但在我看来,两个主要障碍阻碍了RESTful的发展：
>改变 – 它与传统设计的方式截然不同
>挑战 – 设计纯RESTful服务器API和相应的丰富,强大的客户端UI并不容易
Complex GUIs will require a JavaScript
application on the client in many
cases.
在我看来,无论服务器端实现如何,复杂的,丰富的客户端体验都需要一些深入的JavaScript.
You have to stay on the same page and
reload only parts,
这是一种与传统请求/响应整页到完整页面设计截然不同的设计.每种设计都有自己的权衡. REST设计在AJAX调用中运行得特别好,但客户端代码需要精心设计才能保持可维护性和健壮性.
具有胖客户端的RESTful服务器：
>好好扩展：每个用户的会话信息都不会存储在稀缺的服务器内存中
>通过网络减少请求/响应数据：不完整地发送每个页面,不发送会话ID或ViewStates
>干净的可重用URL：提供可以支持多个UI的干净,分离的服务器API
>纯：严格遵守HTTP规范(GETs不会产生副作用等)
>客户体验：对异步事务更丰富,响应更快
但是,正如您所提到的,胖客户端有缺点：
>更容易受到XSS攻击,RESTful URL确实需要谨慎的安全性>复杂的JavaScript可能很难开发,维护和调试(使用OO JavaScript可以帮助调解这一点)>需要向用户指示异步请求正在后台处理>需要更多客户端故障处理逻辑>与服务器端相比,框架和IDE工具在客户端开发方面一直较弱(这种情况正在逐渐好转)
