restful web_RESTful Web服务的新标准

最新推荐文章于 2024-10-01 18:51:18 发布

diluan6799

最新推荐文章于 2024-10-01 18:51:18 发布

阅读量99

点赞数

文章标签： java 大数据人工智能 linux http

restful web

1月， JSR 339以11票赞成的票数通过了JSR审查投票，并且目前正在为RESTful Web Services开发下一版本的JAX-RS API。在这次采访中，我们与Markus Karg谈了JAX-RS 2.0的当前状态，专家组为API计划的计划以及我们是否可以期望JAX-RS 2.0能够如期到达。

JAXenter：专家组已开始研究JAX-RS 2.0。主要的新功能之一是统一的客户端API。您在这里计划了什么？

Markus Karg：在JSR 311下开发的JAX-RS 1.1规范仅集中在服务器区域。到目前为止，还没有标准化的支持以Java编写访问RESTful Web服务的客户端。例如，通过使用JRE类HttpURLConnection（导致相对复杂的代码）或使用专有产品（例如Apache Wink客户端或Jersey客户端）来迫使用户绕行，这导致了不可移植的应用程序。

因此，一方面要简化编写客户端的工作，另一方面又要允许从Wink轻松迁移到Jersey（反之亦然），也必须对客户端进行标准化。原则上，有几种可能的方法可以做到这一点：我们可以就现有产品的API达成一致，但这仅对特定客户有利。我们也可以就全新的API达成共识，但这需要付出更多的努力，而带来的额外好处可能很少。

Oracle并行提出了两种API，一种对“普通用户”具有很高的抽象度，而对于特殊用例则更为复杂。原则上，此处所有选项均处于打开状态。但是，我们只是在此讨论的开始。我们将详细检查现有的API，并确定哪种途径为用户带来最大的收益。

由于Apache离开了Java Community Process，因此有一些倾向于Oracle的趋势，并且Oracle提供Jersey参考实施。这不是赞成泽西主义的论点，因为Red Hat（JBoss）和其他人仍然在专家组中有席位。

JAXenter：对异步进程的支持如何？对于WebSocket支持是否应作为JAX-RS 2.0的一部分，存在争议。

Markus： COMET和WebSockets支持异步消息传递的范例。 COMET是用HTTP制定的一种方法，而WebSockets在HTML级别上充当对应方法。它们允许向客户端“推送”信息，即服务器正在向客户端发送消息，无论客户端何时请求此类通知，该消息都会在此时发生。这为整个客户传输服务器系统节省了成千上万的无用的浪费的请求-响应往返，这在“轮询”原理中是必需的，并增加了消息的真实性。

众所周知，“推送”主要来自于面向消息的中间件领域，例如JMS或AMQP。但是这些通常由专有协议或至少不属于Web层的协议支持，因此它们的处理相对复杂，例如在防火墙设置等方面。

同样，在RESTful应用程序上使用异步消息传递也是有意义的：例如，在交易平台上，服务器可以在客户端之间异步分发价格变化，而无需每个客户端不断请求完整的价格表-甚至没有改变！不幸的是，Oracle无法在JAX-RS 2.0中解决这个问题，并将COMET和WebSockets推迟到更高的规范。

这是否意味着COMET和Websockets会无限期推迟，只有时间可以证明。显而易见的是，Oracle提供了参考实现，而决策过程对此进行了反映。我只能推测出这种排除的原因，但是要记住，即使Oracle也没有无限的资源可供使用。

JAXenter： JAX-RX 2.0还有哪些其他新功能？

Markus：严格地说，许多支持Rest范式的应用程序根本不是RESTful的（甚至有人试图为此类应用程序定义标签），因为它们没有满足一个基本方面的要求：HATEOAS（超媒体作为引擎的引擎）申请状态）。 JAX-RS 2.0将增加对Hypermedia的支持，并将允许应用程序将关系（URI）注入实体，或将它们作为链接头发送给客户端。这样，客户可以从收到的响应中了解关系的含义，并可以使用此知识来启动特定过程。就像浏览器可以告诉用户：“单击此链接下订单”一样，RESTful客户端可以以机器可读的形式获取相同的信息。这样就可以构建复杂的流程，而无需在客户端中对其进行静态编程。

使用HATEOAS，可以控制接下来应执行的步骤，当前处于进程状态的状态，从涉及的客户端和服务器移入已传输的介质本身。客户端和服务器不需要记住任何内容，而是可以通过分析介质并根据其意图来学习所有必需的知识。我认为这是除客户端API之外最重要的新功能。

但是，Oracle已将更多项目添加到议程中，包括对MVC的支持，即使用JAX-RS资源作为控制器，参数验证，用CDI替换其自身的注释（因此可以更紧密地集成到Java EE中）等。可以在JCP.org上查看Oracle建议的项目的完整列表，因为该项目实施了透明的信息策略。

最后但并非最不重要的一点是，用户将所有小的讨论点添加到了跟踪器中，当然，这些讨论点也必须得到专家组的审查。对于许多用户而言，与诸如HATEOAS和COMET之类的大型创新相比，解决这些问题具有更高的价值。意识到这一点，Oracle已承诺修复所有此类问题，这些问题被视为JAX-RS 1.1规范的失败。

JAXenter： JAX-RS的参考实现是Jersey项目。专家组和Jersey开发人员之间的关系是什么？

马库斯（Markus）：一般而言，JCP表示自己是民主的，而专家组则表示自己独立于泽西岛的开发商。正式地，专家组定义了规范，Jersey开发人员以Java代码实现了该规范。但是，实际上，泽西岛的开发人员是Oracle的雇员，由于泽西岛已经能够解决出现的大多数问题，因此Oracle领导工作组，确定议程并为大多数项目提供解决方案。

过去，泽西岛的开发人员参与了与用户和竞争对手的公开和建设性对话。来自其他项目的想法和代码已合并到Jersey，有时直接来自专家。我很好奇，在以前的规范离职后，Oracle的Marc Hadley和Paul Sandoz（都是Sun的前雇员）是否成立，我希望这种对话得以维持，以实现最佳和最广泛采用的标准，并且由于单方面推销自己的产品将对任何人都没有帮助，甚至对Oracle也没有帮助，因为像RestEasy和Wink这样的竞争性实施非常受欢迎。

不幸的是，此JSR缺席了一些前专家，部分原因是出于政治原因，这无法改善其余参与者的状况。我对接下来的几个月会发生什么感到很好奇。

JAXenter：下一步是什么？

马库斯：现任Co Spec负责人Paul Sandoz将于2月离开Oracle。根据JCP章程，Oracle将任命继任者，并且由于桑多斯目前是泽西岛的中心人物，因此将为该项目建立新的开发人员。显然，这不会在一夜之间发生。

一旦发生这种情况，Oracle将协调专家组的下一个阶段：即提供议程，决定要讨论的主题，何时以及以何种形式讨论。在此之前，专家组成员可以自由讨论，但不能做出任何实际决定。简而言之，我们目前正在等待Oracle。

JAXenter：我们什么时候可以期待JAX-RS 2.0的最终版本和参考实现？

马库斯：如果在软件领域中只有一个常数，那就是从未达到发布日期。 Oracle为JSR 339和许多讨论主题提供了严格的日程安排。由于我们不打算只是对现有的Jersey代码加盖戳（而且我不相信，Oracle希望我们这样做），我认为2012年第二季度的建议发布日期非常雄心勃勃。

较小的项目未能满足更慷慨的期限。如果我们能够按时完成发布，我将感到很高兴，但是由于必须协调多个项目，并且专家组成员也必须从事其他项目，因此不可能完成所有的截止日期和主题。

绝对截止日期是Java EE 7的发布日期，因为该平台将包含JAX-RS 2.0。而且，目前还没有为此的JSR。

JAXenter：非常感谢！