11

我正在为宁静的服务选择一个框架。Restlet 看起来很有希望。但是，我想选择一些足够主流的东西，它不会很快失去支持/开发。我知道restlet已经存在了很多年。但是，我想知道它是否足够受欢迎。我的问题是，

  1. 有大牌公司在用吗？
  2. 默认的 http 服务器是否足以用于生产？

谢谢

4

4 回答 4

27

Restlet 框架自 2005 年以来一直可用，当时它是第一个用于 Java 的 RESTful Web 框架。它支持 JAX-RS API，但它自己的 Restlet API 从一开始就是客户端和服务器端，更加全面和可扩展。我们可以根据社区反馈自由进行创新，而无需经历冗长的 JCP 标准化流程。

此外，我们刚刚在去年 9 月发布了“Restlet in Action”一书及其 2.1 版。我们的内部连接器是完全异步的并且基于 NIO，即使它还没有准备好进行大量生产，我们也会不断地稳定它（使用 Jetty 连接器或 Java EE 容器，而无需更改您的 Restlet 应用程序）。

它对 Java SE/EE、OSGi、Android、GAE 和 GWT 的一致支持是独一无二的。JS（Node.js + AJAX）的移植也在进行中。我们还开始了 2.2 版的工作，第一个里程碑已发布（完全支持 Java 6，基于最终规范的 OAuth 2.0 扩展等）。

在参考方面，我们有很多大公司在使用它，包括 LinkedIn（参见他们的 GLU 开源项目）、IBM、NVidia、ForgeRock、NASA、Sonatype、Apache Camel、Mule ESB 等。Google 也在内部使用它。在这里查看一些报价： http ://restlet.com/discover/quotes

1 月份，我们将推出一个新的社区网站以及 APISpark，这是一个直接基于 Restlet 框架 (PaaS) 创建、托管、管理和使用 Web API 的一体化平台，因此该项目是活跃的有一个令人兴奋的未来！

此致，

杰罗姆·卢维尔

PS：我是 Restlet 框架的创建者和首席开发人员。

于 2012-12-23T13:58:10.907 回答
3

你能得到的最主流的是Jersey. 它是java中rest的官方实现。Restlet 在 Jersey 之前出现了。但随后泽西超越了他们（以我的拙见）。我在严肃的项目中使用了 Jersey 和 Restlet。他们都很好。但是，您会在 Jersey 上找到更多支持、更多书籍和更多示例。

于 2012-12-22T07:06:26.680 回答
2

这是关于Java的吗？在这种情况下，JAX-RS 是执行此操作的绝佳新 API。最好的书是带有 JAX-RS 的 Restful Java。我最喜欢的实现是泽西岛，但也有其他的有自己独特的功能。如果您不使用它们的独特功能（无论如何都是次要的），所有 JAX-RS 实现都是兼容的。这本书解释了核心 API、REST 理念，以及不同实现所特有的一些特性。这是一本极好的书。我喜欢这篇介绍，作者在其中讲述了他如何习惯于传统的远程过程调用（如 SOAP、WCF 和普通的 OO 语义），但随后看到 REST 原则的光芒更简单、更优雅。

我使用 Tomcat 作为 HTTP 服务器（servlet 容器）。它是轻量级的，并且是 Amazon Beanstalk 使用的（您只需将应用程序、WAR 文件上传到它，它就可以正常工作）。您还可以使用支持更多 JavaEE 功能的 GlassFish，或者将 Apache 用于静态页面和其他内容，并将 REST 请求转发到 Tomcat/GlassFish。

JAX-RS 令人讨厌的地方在于它非常强大和简单，以至于您很想编写符合意识形态的 REST 服务。不幸的是，javascript 不能使用许多 REST 功能（设置 Accept 标头、调用除 GET/POST 之外的任何内容等），但这没什么大不了的。

如果您的客户端是 Java，Jersey 还有一个出色的客户端 Java API，它反映 JAX-RS 并重用相同的带注释的类。

于 2012-12-22T07:08:33.603 回答
0

从文章

Servlet API 于 1998 年发布，其核心设计从那时起没有发生重大变化。它是最成功的 Java EE API 之一，但它存在一些设计缺陷和限制。例如，URI 模式和处理程序之间的映射受到限制并集中在一个配置文件中。此外，它将套接字流的控制权直接交给了应用程序开发人员，从而阻止了 Servlet 容器的一些 IO 优化，例如完全使用 NIO 功能。最后，它不能很好地支持缓存、内容协商和内容压缩等 HTTP 功能，这给开发人员带来了太多痛苦，并阻止他们专注于他们的应用程序特定代码。

另一个主要问题是 Java EE 堆栈中缺少现代 HTTP 客户端 API。JDK 的 HttpURLConnection 类很难使用，并且有太多的 HTTP 特性不受支持，比如表达客户端对内容协商的偏好。

人们经常依赖第三方 HTTP 客户端 API 来解决这些限制。同样，HttpURLConnection 不支持 NIO。

2005 年，我看到了超越所有这些限制的机会，并根据 REST 原则设计了一个全新的 API。我们第一次拥有一个统一客户端和服务器端 Web 应用程序的 API，一个完全支持 NIO 的 API，以及一个允许开发人员以编程方式控制其容器、连接器和部署的应用程序的 API，而无需一直依赖 XML描述符。

于 2012-12-22T07:04:15.847 回答