restful实现,restful框架

  restful实现,restful框架

  REST(表示状态转移)描述了一个架构风格的网络系统,它指的是一组架构约束和原则。

  RESTful指的是满足这些约束和原则的应用程序或设计。

  RESTful service是一个架构模型,它的轻量级web服务,扮演了HTTP协议的原生GET、PUT、POST、DELETE。

  休息并不总是正确的选择。作为一种设计Web服务的方法,它变得越来越流行,与基于SOAP和WSDL的方法相比,它对专有中间件(如应用服务器)的依赖更少。

  使用REST的关键是如何抽象资源。抽象越精确,REST的应用就越好。

  00-1010 1.给每样东西一个ID

  2.将对象连接在一起

  使用标准方法

  4.资源的多种表达方式

  5.无状态通信

  REST实现是一种解耦方法。让我们实现这些架构特性:性能、可伸缩性、简化、可修改性和可扩展性。

  在J2EE,我们可以使用JAX-RS,drowizard…dot net平台可以使用Web API,WCF,ServiceStack,Nancy FX。

  Web应用最重要的REST原则是客户端和服务器的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求的必要信息。如果服务器在请求之间的任何时间点重新启动,客户端将不会得到通知。此外,无状态请求可以由任何可用的服务器来回答,这非常适合云计算等环境。客户端可以缓存数据以提高性能。

  在服务器端,应用程序的状态和功能可以划分到不同的资源中。资源是一个有趣的概念实体,它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等。每个资源使用URI(通用资源标识符)来获得唯一的地址。所有资源共享一个统一的接口来在客户端和服务器之间传输状态。使用标准的HTTP方法,比如GET、PUT、POST和DELETE。超媒体是应用程序状态的引擎,资源表示通过超链接相互连接。

  另一个重要的REST原则是分层系统,这意味着一个组件不能知道与其交互的中间层之外的组件。通过将系统知识限制在单一层,可以限制整个系统的复杂性,促进底层的独立性。

  当REST架构的约束作为一个整体应用时,它将生成一个可以扩展到大量客户端的应用。它还减少了客户端和服务器之间的交互延迟。统一接口简化了整个系统架构,提高了子系统间交互的可视性。REST简化了客户机和服务器的实现。

  00-1010学完什么是REST,我们再来看RESTful的实现。最近,用RPC风格的架构构建的基于SOAP的Web服务已经成为实现SOA最常用的方法。RPC样式的Web服务客户机通过HTTP向服务器发送一个装满数据(包括方法和参数信息)的信封。打开服务器信封,用传入的参数执行指定的方法。该方法的结果被打包到一个信封中,并作为响应发送回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法和RPC样式的Web服务,只公开一个URI,代表一个端点。它忽略了HTTP的大部分特性,只支持POST方法。

  Web服务的RESTful方法已经成为最常见的替代方法,因为它通过HTTP进行轻量级和直接的数据传输。客户端可以用各种语言实现(比如Java程序、Perl、Ruby、Python、PHP和Javascript[包括Ajax])。RESTful Web服务通常可以代表用户通过自动客户端或应用程序来访问。然而,这个服务的简单性允许用户直接与它交互,使用他们的Web浏览器构建一个GET URL并读取返回的内容。

  在REST风格的Web服务中,每个资源都有一个地址。资源本身是方法调用的目标,所有资源的方法列表都是相同的。这些方法是标准方法,包括HTTP GET、POST、PUT、DELETE,可能还有HEADER和OPTIONS。

  在RPC风格的架构中,重点是方法,而在REST风格的架构中,重点是资源——将使用标准方法来检索和操作信息片段(以表示的形式)。资源表示通过表示中的超链接相互连接。

  Leonard Richardson和Sam Ruby在他们的书RESTful Web Services中引入了术语REST-RPC混合架构。REST-RPC混合Web服务不使用信封包装方法、参数和数据,而是直接通过HTTP传输数据,这与REST风格的Web服务类似。但是它不使用标准的HTTP方法来操作资源。它将方法信息存储在HTTP请求的URI部分。几个知名的Web服务,比如雅虎的Flickr API和del.icio.us API,都使用这种混合架构。

  

REST服务关键原则:

REST 对比RPC

 

   Java 框架有两个 Java 框架可以帮助构建 RESTful Web 服务。erome Louvel 和 Dave Pawson 开发的 Restlet(见 参考资料)是轻量级的。它实现针对各种 RESTful 系统的资源、表示、连接器和媒体类型之类的概念,包括 Web 服务。在 Restlet 框架中,客户端和服务器都是组件。组件通过连接器互相通信。该框架最重要的类是抽象类 Uniform 及其具体的子类 Restlet,该类的子类是专用类,比如 Application、Filter、Finder、Router 和 Route。这些子类能够一起处理验证、过滤、安全、数据转换以及将传入请求路由到相应资源等操作。Resource 类生成客户端的表示形式。

  JSR-311是 Sun Microsystems 的规范,可以为开发 RESTful Web 服务定义一组 Java API。Jersey是对 JSR-311 的参考实现。

  JSR-311 提供一组注释,相关类和接口都可以用来将 Java 对象作为 Web 资源展示。该规范假定 HTTP 是底层网络协议。它使用注释提供 URI 和相应资源类之间的清晰映射,以及 HTTP 方法与 Java 对象方法之间的映射。API 支持广泛的 HTTP 实体内容类型,包括 HTML、XML、JSON、GIF、JPG 等。它还将提供所需的插件功能,以允许使用标准方法通过应用程序添加其他类型。

  

构建 RESTful Web 服务的多层架构

RESTful Web 服务和动态 Web 应用程序在许多方面都是类似的。有时它们提供相同或非常类似的数据和函数,尽管客户端的种类不同。例如,在线电子商务分类网站为用户提供一个浏览器界面,用于搜索、查看和订购产品。如果还提供 Web 服务供公司、零售商甚至个人能够自动订购产品,它将非常有用。与大部分动态 Web 应用程序一样,Web 服务可以从多层架构的关注点分离中受益。业务逻辑和数据可以由自动客户端和 GUI 客户端共享。惟一的不同点在于客户端的本质和中间层的表示层。此外,从数据访问中分离业务逻辑可实现数据库独立性,并为各种类型的数据存储提供插件能力。

 

  图中展示了自动化客户端,包括 Java 和各种语言编写的脚本,这些语言包括 Python、Perl、Ruby、PHP 或命令行工具,比如 curl。在浏览器中运行且作为 RESTful Web 服务消费者运行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都属于此列,因为它们都代表用户以自动化样式运行。自动化 Web 服务客户端在 Web 层向 Resource Request Handler 发送 HTTP 响应。客户端的无状态请求在头部包含方法信息,即 POST、GET、PUT 和 DELETE,这又将映射到 Resource Request Handler 中资源的相应操作。每个请求都包含所有必需的信息,包括 Resource Request Handler 用来处理请求的凭据。

  从 Web 服务客户端收到请求之后,Resource Request Handler 从业务逻辑层请求服务。Resource Request Handler 确定所有概念性的实体,系统将这些实体作为资源公开,并为每个资源分配一个惟一的 URI。但是,概念性的实体在该层是不存在的。它们存在于业务逻辑层。可以使用 Jersey 或其他框架(比如 Restlet)实现 Resource Request Handler,它应该是轻量级的,将大量职责工作委托给业务层。

  Ajax 和 RESTful Web 服务本质上是互为补充的。它们都可以利用大量 Web 技术和标准,比如 HTML、JavaScript、浏览器对象、XML/JSON 和 HTTP。当然也不需要购买、安装或配置任何主要组件来支持 Ajax 前端和 RESTful Web 服务之间的交互。RESTful Web 服务为 Ajax 提供了非常简单的 API 来处理服务器上资源之间的交互。

  Web 浏览器客户端作为 GUI 的前端,使用表示层中的 Browser Request Handler 生成的 HTML 提供显示功能。Browser Requester Handler 可以使用 MVC 模型(JSF、Struts 或 Spring 都是 Java 的例子)。它从浏览器接受请求,从业务逻辑层请求服务,生成表示并对浏览器做出响应。表示供用户在浏览器中显示使用。表示不仅包含内容,还包含显示的属性,比如 HTML 和 CSS。

  

 

  业务规则可以集中到业务逻辑层,该层充当表示层和数据访问层之间的数据交换的中间层。数据以域对象或值对象的形式提供给表示层。从业务逻辑层中解耦 Browser Request Handler 和 Resource Request Handler 有助于促进代码重用,并能实现灵活和可扩展的架构。此外,由于将来可以使用新的 REST 和 MVC 框架,实现它们变得更加容易,无需重写业务逻辑层。

  数据访问层提供与数据存储层的交互,可以使用 DAO 设计模式或者对象-关系映射解决方案(如 Hibernate、OJB 或 iBATIS)实现。作为替代方案,业务层和数据访问层中的组件可以实现为 EJB 组件,并取得 EJB 容器的支持,该容器可以为组件生命周期提供便利,管理持久性、事务和资源配置。但是,这需要一个遵从 Java EE 的应用服务器(比如 JBoss),并且可能无法处理 Tomcat。该层的作用在于针对不同的数据存储技术,从业务逻辑中分离数据访问代码。数据访问层还可以作为连接其他系统的集成点,可以成为其他 Web 服务的客户端。

  数据存储层包括数据库系统、LDAP 服务器、文件系统和企业信息系统(包括遗留系统、事务处理系统和企业资源规划系统)。使用该架构,您可以开始看到 RESTful Web 服务的力量,它可以灵活地成为任何企业数据存储的统一 API,从而向以用户为中心的 Web 应用程序公开垂直数据,并自动化批量报告脚本。

  

什么是REST:

REST 描述了一个架构样式的互联系统(如 Web 应用程序)。REST 约束条件作为一个整体应用时,将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过 HTTP 直接传输数据的特性,RESTful Web 服务成为基于 SOAP 服务的一个最有前途的替代方案。用于 web 服务和动态 Web 应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。Ajax 和 RESTful Web 服务本质上是互为补充的。开发人员可以轻松使用 Ajax 和 RESTful Web 服务一起创建丰富的界面。

 

  以上就是REST架构及RESTful应用程序简介的详细内容,更多关于REST及RESTful的资料请关注盛行IT其它相关文章!

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: