早前, web服务是用于访问“数据记录系统”的事实上的标准。SOAP web 服务因其共享数据的选项,可从任何系统访问的特性以及安全方面的选项而愈加受欢迎。这一类型的架构渐渐成为了企业级架构的代名词。 现在越来越多的项目都在利用这些架构中的API管理特性,推开了Web服务的大门。 Web Services 的遗产
这一定义所缺失的跟它所描述的一样多。 XML 是一种对于人类来说难读的东西。Ws标准是臃肿的。给定了标准的复杂性,围绕这个标准而生的工具是匮乏的。定义本身有时是宽松的,并因此互操作性(这是最初被列举的采用Web服务的主要原因之一)并没有它本应该可以的那样好。 |
除此之外,Web服务已经在其所擅长的领域取得了巨大的成功——大型企业级系统的互操作性。这些企业喜欢这个想法,那就是Web服务能让他们的厂商(在理论上)变得中立。他们也乐见立足标准意味着更加廉价的开发者——当某些东西成为标准之后,就可以被更多的人了解。此外,这能促成企业级服务器厂商之间的军备竞赛,这些人只喜欢销售他们最新且最棒的服务器。这是一种全方位的共赢。 我们能看到REST收获了越来越多的受欢迎度, 而Web服务每天都在失去人气。 REST风格API管理的案例我认为有三件事情成就了 REST风格的API管理 并对Web服务的领域形成了挑战——它们并非都是技术上的。 不断变化的需求世界正在变得越来越快。消费者需要越来越多的实时消息,有时来自之前从未暴露过数据的地方。以一种简单的方式同数据进行直接的交互,并且只是数据,正是新的世界秩序的要求。 因为这种需求的增加,企业们正在将他们的数据集合暴露出来,以鼓励第三方对其进行利用。这种数据的暴露常常只是成就了第三方,而可能并不会对他们自己的底线有直接的影响。这已经创建了一个 "API 经济" 形式。 |
缩短上市时间,减少隐藏复杂性
|
变化的客户端第三,Web Service不再是如今的技术首选,因为移动设备和客户端的UI正朝着时尚发展。这很好的完善了服务端,帮助隐藏了其复杂性。这些应用的开发者们想要关注的是应用的UI,而不是学其它更深入的数据处理技术。怎样访问数据对他们而言几乎是第二考虑,因为他们的技能也不在访问数据上面。他们想要仅仅只是访问数据而已,所以当他们有这样需求的时候,简单就好! 微服务及敏捷开发上述强调的业务需求都面临后续项目迭代时的衍生问题。 微服务正日益流行。 “仅有需要时”访问数据及服务,带着这样的承诺,微服务正在挑战传统的企业SOA(面向服务架构)架构,它很容易使用范例进行API管理。 微服务依旧占据优势, 且工具、架构仍在创新中。即便如此,微服务早以承诺递交恰当数量的系统访问入口(API)挑战着Web Services。这非常好的融入了如今被很多企业采用的敏捷思想中,有些Sprint和一些建设性的技术需要"够用就好"的工作完成A到B的迭代。 我们可以看到敏捷的衍生问题与当今提供服务的API——大约75%的API管理性的项目已被内部关注。这也告诉我们API不是直接通过卖数据赚钱,而是他们预见了当今的最佳实践。 |
我也相信,同样简单的推广将有很多其他的软件产品的后果是客户意识到企业软件并不总是如此严谨。请检查RESTful APIs中发布的预测作进一步阅读。 我已经展示了Web服务在苛刻的标准的世界是如何发展的。这使得Web服务及其相关的架构通过使用通用软件的劳动力和跨厂商的互操作性,以占领市场。 API管理正诞生在实时的世界并不断加速前进。开发者在写入时,丰富的用户界面比数据接口会有更多的考虑。这是在推进简化工具,集成架构和技术。 这一点,正如他们所说,是一个完美的风暴。一旦Web服务将其所有的复杂性被创建,APIs和他们所有的简化和开发者主导的工具,将会加速推广到市场。 我坚信,简化的创建工具是测试和REST的API的配置都是简化其他产品的趋势的前沿 - 但这是另一天! |
本文转自:开源中国社区 [http://www.oschina.net]
本文标题:REST API vs. SOAP Web 服务管理
本文地址:http://www.oschina.net/translate/rest-api-vs-soap-web-services-management
参与翻译:leoxu, 昌伟兄, imqipan, 天波烟客
英文原文:REST API vs. SOAP Web Services Management