restlet有多受欢迎？

Question

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

1. 任何使用它的大牌公司？
2. 默认的http服务器是否足以用于生产？

感谢

Answer 1

自2005年以来，Restlet框架已经成为第一个用于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等。谷歌一直在内部使用它同样。在这里看到一些引用： http://restlet.com/discover/quotes

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

致以最诚挚的问候，

Jerome Louvel

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

Answer 2

您可以获得的最主流是Jersey。这是java中休息的官方实现。 Restlet在Jersey之前问世。但是，泽西队超越了他们（以我的拙见）。我在严肃的项目上使用了Jersey和Restlet。他们都很好。但是，您会在Jersey上找到更多支持，更多书籍和更多示例。

Answer 3

这是关于Java的吗？在这种情况下，JAX-RS是用于执行此操作的强大新API。最好的书是Restful Java with JAX-RS。我最喜欢的实现是泽西岛，但也有其他一些具有自己独特的功能。如果您不使用其独特的功能（无论如何都是次要的），所有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并重用相同的带注释的类。

Answer 4

来自article

  

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

     

另一个主要问题是缺少现代HTTP客户端API   Java EE堆栈。 JDK的HttpURLConnection类很难使用   留下太多的HTTP功能不受支持，如表达客户端   内容协商的偏好。

     

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

     

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