标签:
RESTful
REST (Representation State Transfer) ful 就是 fulfil(履行, 满足, 完成, 落实, 兑现, 实践)
REST 是设计基于命名资源 — 例如,以 Uniform Resource Locators(URL)、Uniform Resource Identifiers(URI)和 Uniform Resource Names(URN)的形式 — 而非消息的松耦合 Web 应用程序的一种风格。REST 巧妙地借助已经验证过的成功的 Web 基础设施 — HTTP。换句话说,REST 利用了 HTTP 协议的某些方面,例如 GET
和 POST
请求。这些请求可以很好地映射到标准业务应用程序需求,诸如创建、读取、更新和删除(CRUD),如表 1 所示:
应用程序任务 | HTTP 命令 |
---|---|
创建 | POST |
读取 | GET |
更新 | PUT |
删除 | DELETE |
请求就像是动词,而资源就像是名词,把两者相关联就形成了对行为的逻辑表达 — 例如, GET
这个文件,DELETE
那条记录。
真正的 REST 之父 Roy Fielding 在他的博士毕业论文中陈述到:REST “强调组件交互的可伸缩性、界面的普遍性、独立部署组件以及使用中间组件来减少交互延迟,增强安全性并封装遗留系统”(参见 参考资料)。构建 RESTful 系统并不难,且这样的系统具有高度的可伸缩性,同时与底层数据松散耦合;这样的系统还可以很好地利用缓存。
Web 上所有的东西(页面、图像等)本质上都是资源。而 REST 正是基于命名资源而非消息的,这就限制了底层技术的曝光,从而给应用程序设计中的松耦合提供了便利条件。例如,下面的 URL 在不暗示任何底层技术的情况下,公开了资源:http://thediscoblog.com/2008/03/20/unambiguously-analyzing-metrics/。
该 URL 表示一个资源 — 一篇名为 “Unambiguously analyzing metrics” 的文章。请求该资源就会调用 HTTP GET
命令。注意该 URL 是基于名词的。基于动词的版本(大概类似 http://thediscoblog.com/2008/03/20/getArticle?name=unambiguously-analyzing-metrics)会违反 REST 原则,因为它以 getArticle 的形式嵌套了一条消息。您也可以设想通过 HTTP 的 POST
命令来发布一个新资源,(比如说,一篇诸如 http://thediscoblog.com/2008/03/22/rest-is-good-for-you/ 的文章)。你还可以设想用关联的、基于动词的 API — 如 createArticle?name=rest-is-good-for-you and deleteArticle?name=rest-is-good-for-you — 这样的调用来拦截 HTTP GET
命令,并最大限度地忽略已有的(并且是成功的)HTTP 基础设施。换句话说,它们不是 RESTful 风格。
REST 的魅力在于任何东西都可以成为资源,且表示方法也可以不同。在前面的例子中,资源为一个 HTML 文件,因此,其响应可能是 HTML 格式的。但是资源也可以是一个 XML 文档、序列化的对象或者 JSON 表示。其实,这些都无关紧要。重要的是资源被命名了,并且与它通信不会影响其状态。不影响状态是很重要的,因为无状态的交互有利于可伸缩性。
引用达芬奇的一句名言 “简洁就是终极复杂”。万维网的实现非常简单,并且无可置否地获得了成功。REST 正是利用了 Web 的简单性,并因此造就了高度可伸缩的、松散耦合的系统,而且事实证明,这样的系统很容易构建。
正如您所看到的,构建 RESTful 应用程序最难的部分在于确定要公开的资源。解决了这个问题之后,再使用开源 Restlet 框架构建 RESTful Web 服务就是小菜一碟了。
http://www.ibm.com/developerworks/cn/education/java/j-rest/j-rest.html
标签:
原文地址:http://www.cnblogs.com/jiahaohk/p/4804912.html