工具类服务
编辑部专用服务
作者专用服务
基于REST架构风格的Web服务的研究和设计
计算机网络技术一直是计算机领域发展的一个重要方面，Web服务(WebServices)技术是最近十年网络技术发展的一个热点。其得到发展的很大原因是由于电子商务的迅速崛起，使得Web应用从局部慢慢发展到全球化。Web服务主要用来定义了应用程序在Internet上实现互操作，拓展了应用程序的功能，实现了软件功能的动态提供。Web服务技术使得网络研究的重点从网络层系统互联向应用层服务集成迁移。Web服务技术不仅是一种网络技术，更是一种新型的软件工程技术。软件的设计从面向对象转而变成面向服务，形成了面向服务的体系结构(Service-Oriented Architecture，SOA)。　　
传统的Web服务的发展是建立在一系列协议和标准的基础上的，这些协议和标准在Web服务发展的过程中得到不断的改进和完善。三大基础的标准是SOAP、WSDL、UDDI，在此基础上形成了BPEL、WS-CDL、WSCI等的高层协议。目前对于语义网的研究比较多，它与Web服务结合起来，形成了语义Web服务，提出了RDF、OWL等。传统Web服务的发展和SOAP协议是分不开的，通过它实现HTTP的远程过程调用(Remote Procedure Call，RPC)。这样的设计带来了不必要的复杂性，使得HTTP成为一种用于传输庞大XML负载的协议。描述信息放在XML里面，服务变地复杂、难以调试。传统的Web服务违背了简单性的Web理念，将Web特有的能力隔离在很多抽象层之下。对此采用表示性状态转移(REST)风格的Web服务，彻底的改变了Web服务的设计，让Web服务回归Web理念。　　
REST架构风格(REST，Representat ional State Transfer)提供了实现Web服务的新的理念，是当今世界最成功的互联网超媒体分布式系统架构之一，它使得人们真正理解了HTTP协议本来面貌。随着REST式的架构成为主流技术，一种全新的互联网网络应用开发的思维方式开始流行。传统的Web服务使用SOAP和RPC。通过面向资源的架构(Resource-Oriented Architecture，ROA)替代RPC式架构。面向资源的架构通过统一的接口，改进了RPC接口复杂且无规律性的缺点；通过暴露内部数据代替RPC的暴露内部算法；通过对资源的设计，实现了Web服务的REST化。　　
我们实现了一个真正意义上的REST式架构风格的Web服务，给出了详细的设计。该服务是在研究del.icio.us网络书签服务的基础上，设计一个REST式的网络书签Web服务，详细设计暴露的资源以及统一的接口。基于Ruby on Rails框架，本文设计了一种全新的完全符合REST思想的设计方式。服务设计主要集中在框架的设计，控制器实现主要的功能，并设计了集中数据的模型。在此基础上设计了数据的表示、HTTP响应并实现了一个简单的客户端。该服务是一个完全的REST式服务，通过与del.icio.us Web服务的比较，得出了用ROA对RPC改进的优点。在此基础上对REST式Web服务与传统Web服务进行比较。
学科专业：
授予学位：
学位授予单位：
导师姓名：
学位年度：
在线出版日期：
本文读者也读过
相关检索词
万方数据知识服务平台--国家科技支撑计划资助项目（编号：2006BAH03B01）(C)北京万方数据股份有限公司
万方数据电子出版社REST风格的优势是什么？
REST风格的优势是什么？为什么要用REST？能不能用简短的语言描述一下，要简短点。 阮一峰的这篇博客看过几遍，清楚也用过REST风格的请求，但是好处是什么？
阮一峰的那篇文章我认为没有讲到实质，他能让人大概知道Restful是啥，但无法令人信服地知道REST是一种和以往不同的、在一定场景下有一定优势的架构方式REST的全称在文章里已经有了，其中的核心是第一个字母R，即资源（Resource）REST的核心在于，当你设计一个系统的时候，资源是第一位的考虑，你首先从资源的角度进行系统的拆分、设计，而不是像以往一样以操作为角度来进行设计我们平时搞系统是这样的：有新建用户功能新建用户需要一个URL往这个URL发送的数据要定义好开始写后端和前端这是以操作为第一位的设计方法，首先我们确认了一个操作，然后围绕这个操作把周边需要的东西建设好，这种方式当然可以架构出一个系统，甚至是一个好系统，但是偶尔会有些问题：操作之间是会有关联，你的设计容易变成“第2个操作要求第1个操作进行过”，这种关系多起来你的系统就乱了你的URL设计会缺乏一致性操作通常被认为是有副作用（Side Effect）的，所以很少有人基于操作去设计缓存之类的东西基于这些问题，我们的另一种方法是基于资源的角度来搞，但这个太难了我至今其实没想明白到底是怎么搞的，但基于资源会有一些好处：各个资源虽然可能有关联，但依旧是能够简单地切掉这些关联导致相互独立的，所以不会有非常乱的耦合性对资源的操作就这么几种，所以很容易设计一致的URL我们明白对资源的读操作是无副作用的，所以能玩缓存但其实现在99%说自己是REST的情况，就是改了个URL风格，用了用PUT和POST，根本没有明白REST是一个什么，也没有按REST的思想来指导设计，在我看来纯粹就是在作秀要说自己会REST，我觉得至少回答2个问题：对于用户登录和用户退出这两个业务需求，REST指导下的架构和设计如何满足批量的删除、修改、新增如何满足
评论区吐槽被人将军，我把我的答案也写上吧，还是以前写的一段话，如果没有同感的话，建议答主还是去看REST那篇论文和Roy Fielding写的一篇吐槽博文~~~~~~~~~我的回答~~~~~~~~~~【原文在：】REST本身不是架构，只是一种架构风格，理解它的时候要参考这个架构风格出现的环境所施加的约束条件。
REST的目的是“建立十年内不会过时的软件系统架构"，所以它具备三个特点：
1. 状态无关 —— 确保系统的横向拓展能力
2. 超文本驱动，Fielding的原话是”hypertext-driven" —— 确保系统的演化能力
3. 对 resource 相关的模型建立统一的原语，例如：uri、http的method定义等 —— 确保系统能够接纳多样而又标准的客户端
从另外一个角度看，第一条保证服务端演化，第三条保证客户端演化，第二条保证应用本身的演化，这实在是一个极具抽象能力的方案。
优点是因为他对uri进行了限制，只用于定义资源。这样看起来比较容易理解。尤其是对简单的对象的增删改查，很好理解。缺点是因为这种限制，导致设计uri变得复杂了。尤其是复杂的关系，操作，资源集合，硬性套用rest原则设计非常困难。在rest基础上的HATEOAS，返回的json里增加了相应的关系和url。这也同样带来问题。好处是对简单的关系，的确可以通过url进一步处理。但对复杂的关系和操作，HATEOAS并不能胜任描述。反而在单纯的数据中增加了一堆垃圾信息。当我们在争论Restful风格到底如何设计才是正宗时，发现心中的困惑不仅没有降低，反而增加了。所以我不会去追求正宗的Restful风格，但愿意使用其思想来处理一些uri。
符合HTTP/1.1规范，易让更多的功能在网站上实现。
应题主要求，简要回答它的优势或优点。首先，REST规范：强调HTTP应当以资源为中心，并且规范了资源URI的风格；规范了HTTP请求动作（PUT，POST等）的使用，具有对应的语义；遵循REST规范的Web应用将会获得下面好处：URL具有很强可读性的，具有自描述性；资源描述与视图的松耦合；可提供OpenAPI，便于第三方系统集成，提高互操作性；如果提供无状态的服务接口，可提高应用的水平扩展性；下面再详细说明一下REST。了解事物，分三步走：【基本概念】REST是一种软件架构模式。核心概念包括：资源（Resource）：在REST中，资源可以简单的理解为URI，表示一个网络实体。比如，/users/1/name，对应id=1的用户的属性name。既然资源是URI，就会具有以下特征：名词，代表一个资源；它对应唯一的一个资源，是资源的地址。表现（Representation）：是资源呈现出来的形式，比如上述URI返回的HTML或JSON，包括HTTP Header等；【实践】怎么用呢？不同的Server端框架提供了各种解决方案。比如JavaEE中的开箱即用的Spring-MVC。但实践过程中，你自然会碰到一些需要思考的问题：1）如何定义资源：一般对应数据库实体（在传统的关系型数据库中）。2）需要对HTTP协议更多的理解URL格式：协议://域名/路径?查询#HASH，实际的一个HTTP请求，还会包括Header（含Cookie、Method等）资源的URI格式：协议://域名/路径，它只是URL的子集，表征一个资源实体。比如，。恰当地理解和返回Http Status（状态码）。200=成功，404=资源不存在，500=服务器端错误等等。3）REST操作一般资源操作只有新增、删除、查询、更新，对应HTTP协议中四类请求：POST、DELETE、GET、PUT。其中，后三个操作是幂等的。（什么是幂等？）查询资源时，更多的参数，比如分页、排序、过滤条件，一般都会放在URL的查询部分（Query String）。新增、更新资源，关于资源实体的内容，一般放在请求体（Request Body）中。实际发送请求，还需要有动词，表示对该资源执行什么样的操作。那么超出这个范围的操作该如何扩展？REST操作返回什么内容？对于删除、新增、更新等操作，通常是返回操作是否成功的标识；如果失败，需要返回错误代码和消息，方便客户端做进一步处理。如果是查询操作，通常包含实体或者实体列表。在最佳实践中，应当还应该返回与此操作相关的其他操作。比如，查询得到实体的响应中，应包含该实体的删除、更新操作的地址。请求和返回的Body，采用什么格式？常见的格式包括XML/JSON/HTML。【优缺点】参见最前面。参考：LinkedIn:REST最佳实践：
根据本人的实践经验来看，资源还是操作应该如何理解这个问题和RBAC权限模型里面的权限定义存在同样的问题。例如编辑某个数据的值，这个到底算是操作还是资源？按我的理解，这个数据本身是资源，但编辑它就是个操作，所以需要在资源和操作两个方面进行授权。你首先需要拥有这个资源，其次还要被允许进行编辑，才能对这个资源做出修改。这两项权限缺一不可。实际上，使用REST接口的应用，大多是社会应用而非企业应用，资源的所有权天然就是明确且固定的。要么是我的，我可以删和改，要么是别人的，我只可以查。那么实际上，操作已经被抽象为GET、POST、PUT、DELETE，那么剩下的，也就只有资源了。至于Login和Logout到底是资源还是操作？我认为是User这个资源的状态的变更。
至少有一个好处，风格统一了，delUser deleteUser removeUser 之类的代码看到不用揪心了，然而为了这些好处重构似乎又浪费工时
风格统一，减少了团队沟通和学习的成本，代码一致性好，同时可以使用很多REST现成框架，比如java的jersey
更有利于前后端彻底的分离
我写的一篇关于RESTful的文章， 供参考：
已有帐号？
无法登录？
社交帐号登录restful是什么架构风格_百度知道REST风格的软件架构 - 简书
下载简书移动应用
写了33203字，被272人关注，获得了396个喜欢
REST风格的软件架构
如果一个网站不是 REST 风格架构，肯会被程序员鄙视一番！
移动互联网的飞速发展，特别是移动互联网，给开发者带来了新的机遇和挑战。手机端除了app，我们还会经常接触到移动web，除了浏览器中，很多app里面也会使用web服务，我们会在手机上面做更多复杂的操作，老一代的系统架构已经不再适应了，需要更加规范和优秀的软件架构来应对今天的挑战，那就是 REST 。
从 HTTP 协议说起
首先的熟悉一个概念 URI，Web上可用的每种资源 -HTML文档、图像、视频片段、程序等 - 由一个通用资源标识符（Uniform Resource Identifier, 简称"URI"）进行定位。例如：/a.jpg
Http协议定义了客户端与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE
若要在服务器上创建资源，应该使用 POST 方法。
若要检索某个资源，应该使用 GET 方法。
若要更改资源状态或对其进行更新，应该使用 PUT 方法。
若要删除某个资源，应该使用 DELETE 方法。
资源多重表述 针对不同的需求提供资源多重表述。这里所说的多重表述包括XML、JSON、HTML等。即服务器端需要向外部提供多种格式的资源表述，供不同的客户端使用。比如移动应用可以使用XML或JSON和服务器端通信，而浏览器则能够理解HTML。
注意：HTTP规范中中，GET用于信息获取，而且应该是安全的和幂等的
实际开发中很多人违背了这个协议
很多人贪方便，嫌 POST 使用表单的麻烦，更新资源时用了GET
对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
另外一个是，早期的但是Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计 。还有一个较为严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。
所以新的一套支持HTTP 软件架构风格出现了。
什么是REST
REST (Representational state transfer）,表征状态转义。是 Roy Fielding 博士在2000年他的博士论文中提出来的一种 软件架构 风格。
越来越多的服务使用这种软件架构来设计和实现，例如：提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。
** 值得注意的是，REST是设计风格而不是标准。而是通过表征（Representional ）来描述传输状态的一种原则。其宗旨是从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。获得这些表征致使这些应用程序转变了其状态。随着不断获取资源的表征，客户端应用不断地在转变着其状态。
REST软件架构使用了CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建（Create）、获取（Read）、更新（Update）和销毁（DELETE），就可以组合成其他无数的操作。其实世界万物都是遵循这一规律：生、变、见、灭。这个原则是源自于我们对于数据库表的数据操作：insert（生）、select（见）、update（变）和delete（灭），所以有时候CRUD也写作为RUDI（read update delete insert）。这四个操作是最基本的操作，即无法再细分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。
REST的要求
客户端和服务器结构
连接协议具有无状态性
能够利用Cache机制增进性能
层次化的系统
应该注意区别应用的状态和连接协议的状态。HTTP连接是无状态的（也就是不记录每个连接的信息），而REST传输会包含应用的所有状态信息，因此可以大幅降低对HTTP连接的重复请求资源消耗。
含状态传输的 Web 服务
含状态传输的 Web 服务（也称为 RESTful Web API）是一个使用HTTP并遵循REST原则的Web服务。它从以下三个方面资源进行定义：
直观简短的资源地址：URI，比如：/resources/。
传输的资源：Web服务接受与返回的互联网媒体类型，比如：JSON，XML ，YAML 等。
对资源的操作：Web服务在该资源上所支持的一系列请求方法（比如：POST，GET，PUT或DELETE）。PUT 和 DELETE 方法是幂等方法。GET方法是安全方法 （不会对服务器端有修改，因此当然也是幂等的）。幂等的意味着对同一URL的多个请求应该返回同样的结果。比如绝对值运算就是一个例子，在实数集中，有abs(a) = abs(abs(a)) 。
REST的实现
各大客户端和服务器端都 REST 的风格架构都有相应的实现，包括 android、IOS 、web端
jquery的ajax 函数
type: 'PUT',
//options GET、POST、DELETE
url: this.myurl,
如果 user 对应到 db 中的一个 表 user，那么关于 user的增删改查操作如下：
get /user/1
// 获取 ID 为1 的用户
// 获取用户列表
// 删除 ID 为1 的用户
{ username:
'123', age: 12}// 更新 ID 为1 的用户
post /user
{ username:
'123', age: 12} 创建用户
express 4.x 版本自带了 rest 的路由
node-restify
restler 客户端使用rest
REST和AJAX
在Ajax出现以前，浏览器的功能相对比较弱，只能实现一些瘦客户端的功能，因此，Web应用的开发者们只能把功能的实现尽量向服务器端移，这样产生了现在被广泛使用的WebMVC架构模式。这样做，其实有很多地方已经违反了REST的架构约束，但在当时是没有办法的Ajax出现后，浏览器的能力大大增强了，这时依靠Ajax的能力真的有可能完全遵从REST的架构约束了，这就需要把许多功能前移，建造更强大的客户端了。这也许就是为什么REST会随着Ajax的出现而渐渐流行开来的原因，当然，Rails DHH的大力推广也有功不可没。
REST的优点
可更高效利用缓存来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
浏览器即可作为客户端，简化软件需求
相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好
众所周知，对于基于网络的分布式应用，网络传输是一个影响应用性能的重要因素。如何使用缓存来节省网络传输带来的开销，这是每一个构建分布式网络应用的开发人员必须考虑的问题。
HTTP 协议带条件的 HTTP GET 请求 (Conditional GET) 被设计用来节省客户端与服务器之间网络传输带来的开销，这也给客户端实现 Cache 机制 ( 包括在客户端与服务器之间的任何代理 ) 提供了可能。HTTP 协议通过 HTTP HEADER 域：If-Modified-Since/Last- Modified，If-None-Match/ETag 实现带条件的 GET 请求。
REST 的应用可以充分地挖掘 HTTP 协议对缓存支持的能力。当客户端第一次发送 HTTP GET 请求给服务器获得内容后，该内容可能被缓存服务器 (Cache Server) 缓存。当下一次客户端请求同样的资源时，缓存可以直接给出响应，而不需要请求远程的服务器获得。而这一切对客户端来说都是透明的。
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
如果你是程序员，或者有一颗喜欢写程序的心，喜欢分享技术干货、项目经验、程序员日常囧事等等，欢迎投稿《程序员》专题。
专题主编：小...
· 175954人关注
欢迎投稿 将实用的知识共享
· 22615人关注
分享Android开发的知识，教程，解析，前沿信息，都可以，欢迎大家投稿~
内容可搞笑，可逗比，另外欢迎申请管理员
· 21261人关注
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式： 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
基于Rest风格OJ平台的设计与实现
下载积分：2500
内容提示：基于Rest风格OJ平台的设计与实现
文档格式：DOC|
浏览次数：0|
上传日期： 14:04:31|
文档星级：
该用户还上传了这些文档
基于Rest风格OJ平台的设计与实现
官方公共微信