REST是GUI Web应用程序的不错选择吗？

基于GUI的Web应用程序可以构建在GUI组件,Wicket等有状态框架上,也可以构建为RESTful,无状态的方式,仅在客户端上具有GUI状态.

从技术角度来看,REST看起来是正确的方式,因为它利用了http的全部功能,并导致高度可扩展的应用程序.但这需要付出代价.在许多情况下,复杂的GUI将需要客户端上的JavaScript应用程序.如果应在客户端维护状态,则必须保持在同一页面并仅重新加载部分.或者你必须使用隐藏的iframe技巧.有时在服务器上有像购物车一样的伪资源,以启用RESTful设计.你必须保持多步对话的中间状态等等......

如果我环顾四周,很少有RESTful GUI Web应用程序.这是因为历史原因还是RESTful设计在常见情况下无效？

如果我环顾四周,很少有RESTful GUI Web应用程序.这是因为历史原因还是RESTful设计在常见情况下无效？

我的回答是主观的,但在我看来,两个主要障碍阻碍了RESTful的发展:

变化 - 它与传统设计的网站方式截然不同

挑战 - 设计纯RESTful服务器API和相应的丰富,强大的客户端UI并不容易

在许多情况下,复杂的GUI将需要客户端上的JavaScript应用程序.

在我看来,无论服务器端实现如何,复杂的,丰富的客户端体验都需要一些深入的JavaScript.

您必须保持在同一页面并仅重新加载部件,

这是一种与传统请求/响应整页到完整页面设计截然不同的设计.每种设计都有自己的权衡.REST设计在AJAX调用中运行得特别好,但客户端代码需要精心设计才能保持可维护性和健壮性.

具有胖客户端的RESTful服务器:

好好扩展:每个用户的会话信息都不会存储在稀缺的服务器内存中

通过网络减少请求/响应数据:不完整地发送每个页面,不发送会话ID或ViewStates

干净的可重用URL:提供可以支持多个UI的干净,分离的服务器API

纯:严格遵守HTTP规范(GETs不会产生副作用等)

客户体验:对异步事务更丰富,响应更快

但是,正如您所提到的,胖客户端有缺点:

RESTful URL更容易受到XSS攻击,确实需要谨慎的安全性

复杂的JavaScript在开发,维护和调试方面具有挑战性(使用OO JavaScript可以帮助调解这一点)

需要向用户指示异步请求正在后台处理

需要更多的客户端故障处理逻辑

与服务器端相比,框架和IDE工具在客户端开发方面传统上较弱(这种情况正在逐渐好转)