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>更多

  • API项目中 官方客户端不再是可有可无的

    在API项目中,有官方支持的客户端才能给API社区传达积极的信息。没有官方支持客户的API就像是没有方向盘的汽车。可能是辆好车,但是却哪儿也去不了。

  • Google收购Apigee,焦点在于企业本身还是API?

    Axway的Suraj Kumar认为Apigee收购案不一定是件好事。尽管Google也许会像Borg一样行动,这也许预示着Google的态度需要转变。

  • Google的新收购是否意味着API变得更酷了?

    Google对API管理解决方案提供商Apigee的收购,我们应该怎么评价呢?是为了打造一个改变游戏的联盟吗?或者只是技术巨头想尽快吞食市场份额的尝试?

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

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

相关推荐

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

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

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

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

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

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

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

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

技术手册>更多

  • 评估成功:衡量BPM的利益

    我们已经在典型的商业预告中听到了一种变奏曲,即不可以改变或者改进无法衡量的东西。没有什么比BPM更能体现这句话了。在这本技术手册中,我们将提供可靠的最佳实践,精确衡量BPM的发展。专家将就如何削减BPM复杂性以及将BPM和重要的客户关系管理流程整合。同样,我们也会提供一些BPM趋势、愿景和技巧。

  • SOA治理

    治理不同于管理。治理规划需要制定什么决策,而管理是制定和实施决策的过程。治理重在建立决策,而管理重在贯彻执行决策。

  • OSGI教程

    OSGI服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理,OSGI技术提供一种面向服务的架构,它能使这些组件动态地发现对方。

  • 敏捷开发技巧指南

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。关于瀑布方法和敏捷方法的分析已经探讨过多次,但瀑布方法在某些项目和开发团队中还存在价值。《敏捷宣言》声明指出,个人和交互高于流程和工具。由于开发项目的利益攸关者已经变得越来越分散,遍布在全球各地,甚至经常横跨了几个时区,基于云的开发环境已成为必备之选而非锦上添花。TT SOA在这本技术手册中将介绍敏捷开发的一些技巧以及瀑布方法和敏捷方法的对比,同时还涵盖了云对于敏捷开发所起到的作用。

TechTarget

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