REST架构及RESTful应用程序简介

REST (REpresentation State Transfer) 描述了一个架构样式的网络系统,指的是一组架构约束条件和原则。

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

RESTful service是一种架构模式,它的轻量级web服务,发挥HTTP协议的原生的GET,PUT,POST,DELETE。

REST 并非始终是正确的选择。 它作为一种设计 Web 服务的方法而变得流行,这种方法对专有中间件(例如某个应用程序服务器)的依赖比基于 SOAP 和 WSDL 的方法更少。

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

REST服务关键原则:

1. 给一切物体一个ID

2.连接物体在一起

3.使用标准方法

4.资源多重表述

5.无状态通信

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

在J2EE中我们可以使用JAX-RS, Dropwizard… 
dotnet平台可以使用Web API, WCF,servicestack,nancyfx

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

在服务器端,应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体,它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面,以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法,比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎,资源表示通过超链接互联。

另一个重要的 REST 原则是分层系统,这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层,可以限制整个系统的复杂性,促进了底层的独立性。

当 REST 架构的约束条件作为一个整体应用时,将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构,改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。

REST 对比 RPC

了解了什么是什么是REST,我们再看看RESTful的实现。最近,使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封(包括方法和参数信息)通过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务,URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。

由于轻量级以及通过 HTTP 直接传输数据的特性,Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言(比如 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 服务,比如 Yahoo 的 Flickr API 和 del.icio.us API 都使用这种混合架构。

RESTful的实现:

RESTful Web 服务的 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的资料请关注我们其它相关文章!

(0)

相关推荐

  • Resty开发restful版本的Jfinal深入研究

    目录 前言 官方实例 一.独有优点: 二.运行EXAMPLE示例: 前言 自发现了resty后,一直进行深入考究到深夜3点才睡,只想说这6个小时的体验博主内心是满足的!说resty是restful版的Jfinal之Resty,其实有点过了,只是大部分人知道Jfinal,不一定知道还有个resty,resty的框架设计大量借鉴了Jfinal极简开发的思想,先抛开resty是否有重复造轮子之嫌!就作者写了大量的Jfinal插件后,提炼出针对restful开发的resty来,我觉得还是有意义的.而且,

  • Resty极简restful框架快速接入Spring

    目录 RestyMaven的快照版 相关链接 Resty从最初开发到现在已经经历了近10个月时间,在github的star数即将进入400,在没有任何推广的情况,目前的情况还是比较可观的,主要感谢关注restful发展的人们. 对于不理解restful的人其实就是一个url地址的规范,但我从来不这么认为,我一直觉得rest是一种理念,就行java教你面向对象一样,rest教你面向资源,不再以功能来实现接口,以对资源的操作方式来实现接口,目前就我自己使用的情况来说,大多是比较好的反响: 1.接口真

  • Gin与Mysql实现简单Restful风格API实战示例详解

    目录 It works main.go 编译运行 数据库 CURD 增删改查 增 查 查询列表 Query 查询单条记录 QueryRow 改 删 组织代码 封装模型方法 Handler函数 组织项目 数据库处理 数据model封装 handler 路由 分组路由 app入口 总结 我们已经了解了Golang的Gin框架.对于Webservice服务,restful风格几乎一统天下.Gin也天然的支持restful.下面就使用gin写一个简单的服务,麻雀虽小,五脏俱全.我们先以一个单文件开始,然

  • 极简的Resty服务端和客户端RESTful框架

    如果你还不是很了解restful,或者认为restful只是一种规范不具有实际意义,推荐一篇osc两年前的文章:RESTful API 设计最佳实践  和 Infoq的一篇极其理论的文章  理解本真的REST架构风格 虽然有点老,介绍的也很简单,大家权当了解,restful的更多好处,还请google 拥有jfinal/activejdbc一样的activerecord的简洁设计,使用更简单的restful框架 部分设计也来自jfinal+activejdbc+restx,也希望大家多多支持开源

  • REST架构及RESTful应用程序简介

    REST (REpresentation State Transfer) 描述了一个架构样式的网络系统,指的是一组架构约束条件和原则. RESTful 指的是满足这些约束条件和原则的应用程序或设计. RESTful service是一种架构模式,它的轻量级web服务,发挥HTTP协议的原生的GET,PUT,POST,DELETE. REST 并非始终是正确的选择. 它作为一种设计 Web 服务的方法而变得流行,这种方法对专有中间件(例如某个应用程序服务器)的依赖比基于 SOAP 和 WSDL 的

  • Erlang中的并发程序简介

    Erlang中基本的并发函数 1)  Pid =spwan(Mod,Func,Args) 创建一个新的进程来执行apply(Mod,Func,Args),与调用进程并列运行,会使用最新的代码定义模块. 2)  Pid!Message 向Pid进程异步发送Message,!为发送操作符 3)  Receive - end 接收消息 复制代码 代码如下: receive            Pattern1[when Guard1]-> Expression1;            Patter

  • 嵌入式C语言轻量级程序架构内核编写

    目录 1.了解程序架构概念和作用 2.了解单片机常见的程序架构 3.轻量级程序架构设计思想 4.程序架构内核代码的实现原理 5.掌握轻量级程序架构内核编写 6.掌握轻量级程序架构内核移植 1.了解程序架构概念和作用 在写单片机程序的时候往往会遇见下面的情况 1.产品功能需要很多不同的延时效果,又不能用delay死延时,比方说按键检测.led不同闪烁效果. 2.程序功能一多起来,整个脑子就混乱了,不知道这么整合起来. 3.不同功能区域的除了共享全局变量或数组以外不知道该怎么做. 实时操作系统rto

  • 解读ASP.NET 5 & MVC6系列教程(1):ASP.NET 5简介

    ASP.NET 5简介 ASP.NET 5是一个跨时代的改写,所有的功能和模块都进行了独立拆分,做到了彻底解耦.为了这些改写,微软也是蛮 拼的,几乎把.NET Framwrok全部改写了一遍,形成了一个.NET Core的东西. 在.NET Core里一切都是可配置的,包括Session.MVC等功能,而一切可配置的功能都是可以在Nuget上进行下载. 目前ASP.NET 5依旧兼容老的.NET Framwrok,但要在进行跨平台的部署,还是只能使用新改版的.NET Core CLR. 目前的A

  • java三层架构原理与作用小结

    三层架构 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了"高内聚,低耦合"的思想. 概念简介 1.表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得. 2.业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理. 3.数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添.删除.修改.

  • Web程序工作原理详解

    1.Web程序工作原理 (1)Web一词的含义 Network:[计算机]电脑网络,网 Web:[计算机]万维网(WorldWideWeb),互联网(Internet) Web程序,顾名思义,即工作在Web上的程序. (2)单机程序工作原理 单机,即不连接到其他计算机的计算机,不在网络中.例如:两单机A.B,只在A上安装有程序X,若要在B上得到X的运行结果,则必须在B上安装一遍X,然后运行.若B类的计算机比较多,则需要逐一安装运行.它们之间不能直接进行通信和协作.如图1所示. (3)客户机/服务

  • 微信小程序开发的基本流程步骤

    一,微信小程序简介 1,微信小程序简称小程序,张小龙在微信公开课 Pro 上发布的小程序正式上线,时间是2017年1月9日. 2,微信小程序这个词可以分解为"微信"和"小程序"两部分 (1),其中"微信"可以理解为"微信中的",指的是小程序的执行环境:当然微信在提供执行环境的同时也延长了用户使用微信的时间. (2),"小程序"是说它首先是程序,然后具备轻便的特征.小程序并不像其他应用那样,它不需要安装,而是

  • 微服务全景架构全面瓦解

    目录 1 微服务优势与挑战 1.1 微服务的优势 1.1.1 单一职责 1.1.2 轻量级通信 1.1.3 独立性 1.1.4 进程隔离 1.1.5 混合技术栈和混合部署方式 1.1.6 简化治理 1.1.7 安全可靠,可维护. 1.2 面临的挑战 1.2.1 分布式固有复杂性 1.2.2 服务的依赖管理和测试 1.2.3 有效的配置版本管理 1.2.4 自动化的部署流程 1.2.5 对于DevOps更高的要求 1.2.6 运维成本 2 微服务全景架构 3 微服务核心组件 3.1 服务注册与发现

  • 浅谈ASP.NET中多层架构

    很多人对开发多层应用程序感到一定的困难.来看一个例子:对于一个只有一两个人的小公司,一个人可能同时担当老板.出纳.会计.市场.销售.开发等多项工作.而对于一个大公司,就会进行比较严密的分工,每个人只完成一部分工作,需要彼此配合才能保证正常运转.以前的开发程序就类似于一个小公司,从用户界面到数据库访问等所有功能都在一个页面内完成,这样的缺点有: 1. 开发起来比较困难,很难实现多人协作开发 2. 一旦数据库或规则有变,就可能要重新修改整个页面,加大维护成本 3. 因为所有功能都混合在一起,程序重用

  • 设计模式中的组合模式在JavaScript程序构建中的使用

    定义 组合,顾名思义是指用包含多个部件的对象创建单一实体. 这个单一实体将用作所有这些部件的访问点,虽然这大大简化了操作,但也可能具有相当的欺骗性,因为没有哪种隐性方式明确表明该组合包含多少部件. 组合模式的目标是解耦客户程序与复杂元素内部架构,使得客户程序对待所有子元素都一视同仁. 每个子节点都可以使复杂的存在,对于父节点来说,不需要知道子节点的复杂性或者实现子节点的复杂性,只需要关注子节点的特定方法,便可以使用子节点.简化了父和子之间的关系. 对于子节点来说也是一样的,过多的接口暴露有时候也

随机推荐