RESTful API设计给开发人员带来怎样的未来?

日期:2016-3-8作者:Tom Nolle翻译:崔婧雯 来源:TechTarget中国 英文

RESTful API   API设计   BPM   

【TechTarget中国原创】

业界正在逐渐承认RESTful API优于面向服务架构。但是这对于架构师和开发人员而言到底意味着什么?Tom Nolle分享了他的想法。

在模块化应用世界里,最为持久的争论莫过于面向服务架构和表述性状态转移之争了。本文探讨这样的争论带来了什么及其背后的原因。

SOA已经被定性为连接组件和工作流的严格的且重量级的方案,REST则赢得了更多的赞誉。两者的特征都是简化,但是要学习RESTful API设计,架构师和开发人员必须理解SOA和REST之间的差异,学习REST和云以及微服务一起的演进,并且了解如何构建稳定且合规的RESTful工作流。

SOA广义上指基于连接的组件化服务的应用设计,基于这个定义,REST实际上是SOA的一种实现。实际API之争是在简单对象访问协议(SOAP)及实现其Web服务标准和REST之间。这两者有着本质的不同:SOAP从用于扩展网络连接之上的模块化编程的远地过程调用演进而来,而REST从互联网组件的“资源”角度而来。

有状态 vs. 无状态


使用SOAP,网络连接的组件是模块,也就是说他们可以被看成带有功能调用和参数的“过程”或者“类”。SOAP的目标是使得过程能够在远程工作,包括让开发人员找到过程,并且将其正确绑定到执行上。在REST的世界里,组件代表请求访问的资源——一个内部实现细节不透明的真正黑盒子。SOAP里不会假定远程组件是无状态的。本地过程以及REST则会假定调用是无状态的;在执行之间RESTful服务不会驻留任何东西。

云计算和微服务几乎已经使得RESTful API成为了既定业界标准,因此对于开发人员和架构师而言需要重点理解REST。

正是REST的无状态特征使其在云应用里作用非凡。当错误发生时,无状态组件可以随意重新部署,也可以在负载改变时随意伸缩。因为任意请求都可以发送到组件的任意实例上;不会有任何东西保存在另一个实例里,而需要下一次事务“记忆”住的。SOAP开发也可以这么实现,但并不是必须的。

基于这个原因,Web场景下更喜欢使用REST,不过在云服务里RESTful模型也很有用,因为通过API绑定到某个服务一般而言就是控制URL解析的方式。如果一个应用通过URL“知道”某个组件或者微服务,那么如果服务最初的实例出现故障,改变URL相关联的IP地址就会让请求路由到新的实例里。不需要其他额外的目录管理。如果URL指向某个负载均衡器,那么使用简单的算法就可以分发工作,因为没有哪个请求特别需要某个“记忆”了状态的特定实例来处理。

云和微服务


云计算和微服务几乎已经使得RESTful API成为了既定业界标准,因此对于开发人员和架构师而言需要重点理解REST。这意味着在应用里需要解决状态控制的一致性,管理安全性,从而解耦合组件并且创建高效的服务目录。

REST里有两种管理状态的方式——在RESTful调用里将状态传递给服务,或者由服务的任意实例都可以访问的后台数据库来维护状态。如果想要RESTful应用像基于SOAP的应用一样合规,那么就需要采取一致的方案。除非访问后台状态数据库的方案不现实,否则都应该考虑优先选择后台状态管理。客户端状态控制在客户端实例故障时会导致问题。

保证安全性


REST的安全问题很可怕,但是大多数情况下,这些安全问题的假设都是应用组件放置在开放的互联网或者VPN里。简单确定组件部署处的私有的RFC1918地址空间,可以大幅提高REST安全性。当组件间大规模集成对于应用而言必不可少时,这样的方案就不适用了,那么就有必要使用安全连接,比如https。身份令牌也可以作为RESTful API数据包的一部分。

有很多REST目录服务,ProgrammableWeb可能是其中最知名的服务,但是它们都关注于公开暴露的API。Internet社区内部关于私有RESTful API是否自相矛盾这个问题上存在争议,但是从实用的角度,大多数公司都需要使用私有API目录,从而让开发人员可以访问其RESTful API。否则,肯定会影响到企业数据和合规需求。

如果你在考察RESTful API目录工具,首先需要关注那些为微服务而设计的工具,因为这是云API领域的整体趋势。核心需求是支持三层API——私有内部或者甚至部门的API,“合作伙伴”或者社区API以及公开API。不过要记住,如果可以在网络地址空间里访问Web服务或者微服务,它就有可能被hack。即使API目录有安全保障,也同时需要考虑恰当的地址控制或者工作流加密。

REST和微服务使得组件整合更为容易,并且提供了云和虚拟化应用大规模扩展和弹性的可能性。通过解耦合SOAP引入的组件绑定规则来实现,那么应用规划师和开发人员可以通过其他方式实现安全和合规支持。REST和微服务在业界快速得到大量支持,因此需要在你的应用里准备好使用它们。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Tom Nolle
Tom Nolle

关于作者:Tom Nolle是CIMI公司的总裁,这家公司成立于1982年,是致力于电信和数据通信的战略顾问公司。Tom Nolle是IEEE、ACM、Telemanagement Forum和IPsphere Forum的一员,著作有关于Netwatcher方面的书籍。

API>更多

相关推荐

  • 在iBPM和BPM间做选择 不一定非此即彼

    大多数系统都有一样的能力,在很多人看来,除了BPM或者iBPM这两个标签以外,实际上它们之间并没有任何区别。

  • 如何创建成功的RESTful API设计

    设计好的API是一项困难的任务,存在很多主观指标。哪怕是完全拥抱RESTfulAPI设计并对其问题域拥有完整视图的小型初创企业最终也会出现命名不一致、界面模糊以及无记录语义等问题。

  • API创建影响生产的六个方面

    在API创建方面,简单性至关重要。AnyPresence的Vivek Gupta讨论了开发者可以从6个方面处理好API的创建问题,从而加速API生产。

  • 开发人员:构建API时先自己试试

    为已有产品构建API的挑战是,业务需求总是最重要的。为了跟上业务需求的脚步,我们通常被强迫在产品质量上作出让步,也绝对是API开发的最差方式。

技术手册>更多

  • SOA与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

  • 企业架构师风向标

    企业架构师(Enterprise Architect)是企业IT的总体规划和设计师,他们总揽企业的业务流程、应用、数据、和技术等各个方面,兼分析师、设计师、教师、顾问、监察等数职于一身。好的架构师要具有高屋建瓯的视角,统揽全局的能力,深入的行业业务和技术知识,丰富的开发和实施IT项目的经验。目前在中国的多数企业中,企业架构师仍然是一个新的概念。在这本指南中,我们将为您介绍企业架构师面临的最大挑战和应具备的技能,以及在一些具体领域所起到的作用。

  • SOA标准组织:W3C

    W3C是专门致力于创建Web相关技术标准并促进Web向更深、更广发展的国际组织。到目前为止,W3C已开发了超过50个规范(草案)。这些规范(草案)包括人们早已耳熟能详的HTML、HTTP、URIs、XML等,也包括针对语义Web的RDF、OWL等。

  • Web服务描述语言:WSDL

    Web服务描述语言WSDL是用XML文档来描述Web服务的标准,是Web服务的接口定义语言,是Web Services Description Language的缩写它用一种和具体语言无关的抽象方式定义了给定Web服务收发的有关操作和消息。就其定义来说,你还不能把WSDL当作一种对象接口定义语言,WSDL保持协议中立,但它确实内建了绑定SOAP的支持,从而同SOAP建立了不可分割的联系。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算