我正在为一个宁静的服务选择一个框架.Restlet看起来很有前景.但是,我想选择一些足够主流的东西,以免它过早地失去支持/开发.我知道restlet已存在很多年了.但是,我想知道它是否足够受欢迎.我的问题是,
谢谢
Jer*_*vel 26
Restlet Framework自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等.谷歌也在内部使用它.请参阅此处的一些引用:http: //restlet.com/discover/quotes
1月份,我们将推出一个新的社区网站以及APISpark,这是一个直接基于Restlet Framework(PaaS)创建,托管,管理和使用Web API的一体化平台,因此该项目是活跃的,有一个美好的未来!
最好的祝福,
杰罗姆·洛维尔
PS:我是Restlet Framework的创建者和首席开发者.
来自文章
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 以及一个让开发人员以编程方式控制其容器、连接器和部署的应用程序而无需不断依赖 XML 的 API描述符。
| 归档时间: |
|
| 查看次数: |
12659 次 |
| 最近记录: |