11

安らかなサービスのためのフレームワークを選択しています。Restletは有望に見えます。ただし、サポートや開発がすぐに終了しないように、主流のものを選びたいと思います。私はレストレットがかなり前から出回っていることを知っています。しかし、それが十分に人気があるかどうか知りたいです。私の質問は、

  1. それを使用している有名企業はありますか？
  2. デフォルトのhttpサーバーは本番環境に十分対応できますか？

ありがとう

4

4 に答える 4

27

Restlet フレームワークは、Java 用の最初の RESTful Web フレームワークであった 2005 年から利用可能です。JAX-RS API をサポートしていますが、独自の Restlet API は初日からクライアント側とサーバー側の両方であり、はるかに包括的で拡張可能です。長い JCP 標準化プロセスを経る必要なく、コミュニティからのフィードバックに基づいて自由に革新できます。

また、昨年 9 月に「Restlet in Action」という本とそのバージョン 2.1 を出版したばかりです。当社の内部コネクタは完全に非同期で、NIO に基づいており、まだ大規模な製品の準備が整っていませんが、常に安定化しています (Restlet アプリケーションを変更せずに Jetty コネクタまたは Java EE コンテナを使用してください)。

専用エディションによる 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 月には、Restlet Framework (PaaS) に直接基づいて、Web API を作成、ホスト、管理、および使用するためのオールインワン プラットフォームである APISpark と同様に、新しいコミュニティ Web サイトを立ち上げる予定です。エキサイティングな未来があります！

よろしくお願いします、

ジェローム・ルーヴェル

PS: 私は Restlet Framework の作成者であり、主任開発者です。

于 2012-12-23T13:58:10.907 に答える
3

あなたが得ることができる最も主流はですJersey。これは、JavaでのRESTの公式実装です。ジャージーの前にレストレットが出ました。しかし、その後、ジャージーはそれらを上回りました（私の謙虚な意見では）。私は深刻なプロジェクトでJerseyとRestletの両方を使用しました。どちらも良いです。ただし、Jerseyには、より多くのサポート、より多くの本、およびより多くの例があります。

于 2012-12-22T07:06:26.680 に答える
2

これはJavaのことですか？その場合、JAX-RS はこれを行うためのすばらしい新しい API です。これに最適な本はRestful Java with JAX-RSです。私のお気に入りの実装は Jersey ですが、他にも独自の機能を持つものがあります。すべての JAX-RS 実装は、それらの特徴的な機能 (いずれにせよ重要でない) を使用しない場合、互換性があります。この本では、コア API、REST の哲学、およびさまざまな実装に固有の機能の一部について説明しています。それは優れた本です。著者が従来のリモート プロシージャ コール (SOAP、WCF、通常の OO セマンティクスなど) にどのように慣れていたかを説明しているが、REST 原則の光がより単純でより洗練されていることを理解したという紹介が大好きです。

HTTP サーバー (サーブレット コンテナー) として Tomcat を使用します。これは軽量であり、Amazon Beanstalk が使用するものです (アプリケーション、WAR ファイルをアップロードするだけで動作します)。さらに多くの JavaEE 機能をサポートする GlassFish を使用したり、静的ページなどに Apache を使用して、REST 要求を Tomcat/GlassFish に転送したりすることもできます。

JAX-RS の厄介な点は、非常に強力で簡単なため、イデオロギー的に健全な REST サービスを作成したくなることです。残念ながら、JavaScript は多くの REST 機能 (Accept ヘッダーの設定、GET/POST 以外の呼び出しなど) を使用できませんが、大したことではありません。

Jersey には、クライアントが Java の場合、JAX-RS をミラーリングし、同じ注釈付きクラスを再利用する素晴らしいクライアント側 Java API もあります。

于 2012-12-22T07:08:33.603 に答える
0

記事から

サーブレットAPIは1998年にリリースされ、そのコア設計はそれ以降大幅に変更されていません。これは最も成功したJavaEEAPIの1つですが、いくつかの設計上の欠陥と制限があります。たとえば、URIパターンとハンドラーの間のマッピングは制限され、1つの構成ファイルに一元化されます。また、ソケットストリームの制御をアプリケーション開発者に直接提供し、NIO機能の完全な使用などのサーブレットコンテナによる一部のIO最適化を防ぎます。最後に、キャッシュ、コンテンツネゴシエーション、コンテンツ圧縮などのHTTP機能を十分にサポートしていないため、開発者は非常に苦痛になり、アプリケーション固有のコードに集中できなくなります。

もう1つの大きな懸念は、JavaEEスタックに最新のHTTPクライアントAPIがないことでした。JDKのHttpURLConnectionクラスは使いにくく、コンテンツネゴシエーションのクライアント設定を表現するなど、サポートされていないHTTP機能が多すぎます。

多くの場合、人々はこれらの制限を回避するためにサードパーティのHTTPクライアントAPIに依存していました。繰り返しますが、NIOはHttpURLConnectionではサポートできません。

2005年には、これらすべての制限を超えて、RESTの原則に照らして新しいAPIを設計する機会を見ました。初めて、クライアント側とサーバー側のWebアプリケーションを統合するAPI、NIOを完全にサポートするAPI、および開発者がXMLに常に依存することなく、コンテナー、コネクター、およびデプロイされたアプリケーションをプログラムで制御できるようにするAPIを導入しました。記述子。

于 2012-12-22T07:04:15.847 に答える