REST Web 服务介绍

在项目上使用到了Rest技术，应该是Rest的服务概念才对。主要是对外（BPM）暴露API来提供Service。推荐一篇有质量的文章，接下来会系统一点的学习一下Restful概念。http://kb.cnblogs.com/page/91827/

 

     REST介绍

　　若是要说什么是REST的话，那最好先从Web（万维网）提及。

　　什么是Web呢？读者能够查看维基百科的词条(http://zh.wikipedia.org/zh-cn/Web)，具体的我就很少说了。总之，Web是咱们在互联网上最经常使用的服务，甚至在某些人的心中，互联网就是Web。固然，Web只是互联网的一部分而已，只是你们用的最多而已，咱们访问的全部网站都是基于Web。

　　那么，Web和REST之间究竟有什么关系呢？咱们接下来将聊聊组成Web的几大基础技术，URI（统一资源标识符，用来标识资源）、HTTP（超文本传输/转移协议，用来操做资源）、Hypertext（超文本，用来描述资源的内容与状态，咱们能够用HTML、XML、JSON或者自定义格式的文原本描述任何一个资源）。

　　那咱们再来看看什么是REST呢？其实REST并非一种新兴的技术语言，也不是什么新的技术框架。准确来讲说REST只是一种概念、风格或者约束，是回归HTTP自己的建议。

　　REST是由Roy Thomas Fieding在他的博士论文《Architectural Styles and the Design of Network-based Software Architectures》(《架构风格与基于网络的软件架构设计》)中提出的一种架构思想。Roy Fielding是Apache基金会的合做创做者，同时也是HTTP、URI等Web基础协议的主要设计者。从Roy Fielding的背景，我想你们就应该能了解到REST与Web之间的关系了吧。的确，在REST中咱们关注技术实际上也只是URI、HTTP、Hypertext而已。

　　Roy在他的论文中提出了一个RESTful应用应该具有的几点约束。

• 每一个资源都应该有一个惟一的标识
• 使用标准的方法来更改资源的状态
• Request和Response的自描述
• 资源多重表述
• 无状态的服务

　　Roy认为，只有具有了上面的约束的应用才能算是REST应用，其实如今好多所谓的REST应用或服务，其实并不能算是真正的REST应用。

　　我发现，其实目前不少所谓的REST应用，只是RPC而已，出现这样的状况其实很正常，由于RPC实际上更符合通常程序员的思惟。其实REST和RPC之间仍是有很大的差别的，下面咱们说一说REST和RPC之间的区别。

• REST强调资源有惟一的URI；而RPC更增强调过程（动词），由统一的接口来调用它们。
• REST回归HTTP最初的设计；RPC仅仅只是把HTTP做为传输协议来使用。
• REST是由超文本驱动的；RPC是由方法驱动的。
• REST强调HTTP通讯的语义可见性，经过消息头和标准的HTTP方法来体现；RPC把语义封装在HTTP消息体中。

 

　　REST的应用场景

　　经过上面的介绍，你们应该对REST有一些最基本的了解，因为RESTf应用的这些约束，咱们能够很轻易的了解和使用REST的服务（只要你了解HTTP）。

　　其实，咱们常常容易犯一个错误就是，当咱们了解了一个新的技术，就会用这个技术来解决全部的问题。有一句谚语是这么来讲的：“在锤子的眼里，全部的东西都是钉子”，其实REST也只是咱们工具箱里面的其中的一个工具而已，但愿不要把它当作咱们惟一的工具。那么咱们就来聊聊适合使用REST的应用场景和不适合使用REST的应用场景。

　　在我看来REST最适合的应用场景实际上是须要对外暴露服务的时候，这个时候，咱们能够充分利用REST的自描述、无状态、惟一标识等特性来提供清晰、友好的API，并且如今的Jesery、RESTEasy等JAX-RS框架也提供了OAuth的支持，基本上可以保证服务安全。

　　最不适合的应用场景是对性能要求高的系统内部之间的服务调用，当你在这个时候使用REST的话，那么REST全部的特性都会变成拖累。这个时候，仍是须要选择更底层的通讯协议和方式会更好一些，好比ICE。这样的错误，我曾经犯过，后来经过很长时间的努力才慢慢的将这个错误改过来。

 

　　规划REST服务

　　当咱们要规划一个REST服务的时候，其中最关键的概念其实就是“资源”。

　　资源是什么呢？广义上讲，任何事物只要它有用，那么它就是资源。狭义的讲（在Web环境中），它是一个能够存放、链接在计算机上，能够经过比特流进行操控的实体。一个实体想成为资源，它必须有一个URI。在这里URI包含了两重含义：1)它是资源的名称 2)它是资源的地址。

　　在咱们规划URI的时候，有几点但愿你们可以注意一下：

• 一个URI标识一个资源，可是一个资源能够被多个URI标识。
• 资源也是有层次的，这个层次应该在URI上充分的体现出来。
• 在规划URI的时候，须要定义一些团队内部确认的关键字或符号，这些关键字或符号是有特殊意义的，不能随便使用。
• 须要有一个URI定义的文档，以备之后的查询和维护。
• 可使用URI Template来描述URI的定义。如何使用URI Template也看看这篇文章

　　当咱们定义好资源以后，接下来要作的事情就是定义操做资源的方法以及资源的表述格式了。

　　使用HTTP提供的基本方法来对资源进行操做，通常的操做定义以下：POST（建立资源）、GET（获取资源）、PUT（修改资源）、DELETE（删除）。它们正好对应了CRUD。

　　对资源的表述，通常的选择会是XML，可是我更加推荐使用JSON来表述资源。在网络中的传输量也小，并且也便于JavaScript来解析，并且如今其余语言解析也是很是方便的事情。不过，最关键的仍是占用更少的资源，让一样的资源可以服务更多的人。

　　下面的这张图就很好的说明了REST中最重要的围绕资源的三角关系。

　　在InfoQ上有一篇很好的文章来介绍如何规划REST服务《如何获取（GET）一杯咖啡——星巴克REST案例分析》，估计你们看完这篇文章，应该对如何规划REST服务会有更深的认识。

 

　　选择一个快速方便的REST框架

　　如今REST的框架也很是多，推荐你们使用Jersey和RESTEasy来建立本身的REST服务。

　　这两个框架都出自名门，Jersey是由SUN提供的JAX-RS实现参考，对JAX-RS支持的最为充分和快速，基本上全部的JAX-RS的新特性都会在Jersey里第一个体现出来，并且提供了至关全的例子让你学习。RESTEasy则是由JBoss开源的项目，它一样有不少优势，并且文档也比Jersey更好一些，可是和他JBoss应用服务器绑定的比较紧密，这点我我的不太喜欢，若是是熟悉JBoss应用服务器的人能够选择RESTEasy，它给人的感受更加成熟一些，不像Jersey会很快的加入新的特性。不过，须要根据我的本身的喜爱来选择。

　　如何使用Jersey来快速建立REST应用，参见经过Jersey快速构建REST应用，如何使用RESTEasy快速建立REST应用，参见使用RESTEasy快速建立REST应用。

 

　　发布REST服务须要注意的地方

　　以前我也提到了使用REST的最佳的场景是对外提供公开的服务，也就是所谓的OpenAPI。一旦开放了API，咱们就很难控制这些API的使用及其调整了，若是在开放这些API以前考虑的不周到的话，那么后期的维护那就会是一个很是麻烦的事情了。因此，当咱们决定要开放API的时候，那么咱们必定要注意一些事情，下面的这些算是个人经验总结。

　　对外暴露API时，须要注意版本规划，以便之后API的升级和维护。API的版本规划，在开始开放API的以前，是一件很容易被忽视的。可是一旦你的API开放以后，那么你就会发现，没有对开放的API进行版本规划，是一件很是愚蠢的事情。当你的API使用的人愈来愈多，当你的开放的API愈来愈多，一旦某个API要升级，输入和输出发生变化的时候，你根本不知道该通知谁来升级，解决问题的时候也很是麻烦。

　　一样，因为对外暴露API以后，你很难控制API被调用的次数和意图，须要在一些关键的API被调用的次数和频率上进行控制，以避免受到恶意的攻击。可是，到底次数和频率应该控制在一个什么样的程度，就要看你的API的关键程度以及负载能力了，每一个系统都会有本身的评判，只要你掌握好了这个尺度，应该都不会有问题的。

　　另外，因为如今浏览器的限制，只能使用HTTP的GET和POST方法，若是经过AJAX直接调用REST服务，当你的服务中须要使用HTTP的PUT或者DELETE方法来调用的话，最好是考虑使用重载POST方式将须要使用PUT和DELETE方法调用的服务可以经过POST来调用。