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

概述基于GUI的Web应用程序可以构建在GUI组件,Wicket等有状态框架上,也可以构建为RESTful,无状态的方式,仅在客户端上具有GUI状态. 从技术角度来看,REST看起来是正确的方式,因为它利用了http的全部功能,并导致高度可扩展的应用程序.但这需要付出代价.在许多情况下,复杂的GUI将需要客户端上的JavaScript应用程序.如果应在客户端维护状态,则必须保持在同一页面并仅重新加载部 基于GUI的Web应用程序可以构建在GUI组件,Wicket等有状态框架上,也可以构建为RESTful,无状态的方式,仅在客户端上具有GUI状态.

从技术角度来看,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工具在客户端开发方面一直较弱(这种情况正在逐渐好转)

总结

以上是内存溢出为你收集整理的REST是GUI Web应用程序的不错选择吗？全部内容，希望文章能够帮你解决REST是GUI Web应用程序的不错选择吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。