4 RESTful Webサービス・アプリケーションの構築、パッケージ化およびデプロイ
Oracle WebLogic Serverには、Jersey 2.x Java API for RESTful Web Services (JAX-RS) 2.0参照実装(RI)を使用して、Representational State Transfer (REST)アーキテクチャ・スタイルに従ったJava EE Webサービスをパッケージ化およびデプロイする際に必要なコンポーネントとユーティリティが用意されています。
RESTful Webサービス・アプリケーションの構築
RESTful Webサービス・アプリケーションのパッケージ化
すべてのRESTful Webサービス・アプリケーションはWebアプリケーションの一部としてパッケージ化される必要があります。WebサービスがEJBとして実装される場合、WAR内にパッケージ化およびデプロイされる必要があります。
表4-1に、RESTful Webサービス・アプリケーションに使用できる特定のパッケージ化オプションの概要を示します。
表4-1 RESTful Webサービス・アプリケーションのパッケージ化オプション
パッケージ化オプション | 説明 |
---|---|
アプリケーション・サブクラス |
アプリケーション・サブクラスとのパッケージ化を参照してください。 |
サーブレット |
|
デフォルト・リソース |
前述のオプションのいずれかを使用して、構成内にサーブレットのコンテキスト・パスを構成しない場合、WebLogic ServerによってデフォルトのRESTful Webサービス・アプリケーション・サーブレットのコンテキスト・パス |
アプリケーション・サブクラスとのパッケージ化
このパッケージ化シナリオでは、javax.ws.rs.core.Application
を拡張するクラスを作成して、RESTful Webサービス・アプリケーション・デプロイメントのコンポーネントを定義し、追加のメタデータを提供します。Java EE 7 API仕様のjavax.ws.rs.core.Application
を参照してください。
Application
サブクラス内で、必要に応じて、getClasses()
およびgetSingletons()
メソッドをオーバーライドし、RESTful Webサービス・リソースのリストを戻します。リソースはそれを戻すApplication
サブクラスにバインドされます。
両方のメソッドが同じリソースを戻す場合、エラーが戻されることに注意してください。
javax.ws.rs.ApplicationPath
アノテーションを使用して、サーブレットにマップされる基底URIパターンを定義します。この情報がリソースの基底URIで使用される方法の詳細は、「実行時の処理: 基底URIの構成方法」を参照してくださいJava EE 7 API仕様の@ApplicationPath
アノテーションを参照してください。
単純なデプロイメントの場合、web.xml
デプロイメント記述子は必要ありません。より複雑なデプロイメントの場合、たとえばWebサービスの保護や初期化パラメータの指定の際は、「サーブレットとのパッケージ化」に示すように、web.xml
デプロイメント記述子をアプリケーションでパッケージ化できます
例4-1に、javax.ws.rs.core.Application
を拡張し、@ApplicationPath
アノテーションを使用してリソースの基底URIを定義するクラスの例を示します。
例4-1 javax.ws.rs.core.Applicationを拡張するクラスの例
import javax.ws.rs.core.Application; javax.ws.rs.ApplicationPath; ... @ApplicationPath("resources") public class MyApplication extends Application { public Set<Class<?>> getClasses() { Set<Class<?>> s = new HashSet<Class<?>>(); s.add(HelloWorldResource.class); return s; } }
あるいは、次のAPIを使用して、指定されたクラスパスまたは一連のパッケージ名がないかルート・リソースおよびプロバイダ・クラスをスキャンします。
-
org.glassfish.jersey.server.ResourceConfig
(Jersey 2.22 User GuideのJAX-RS Application Modelを参照)
サーブレットとのパッケージ化
次の項では、Webアプリケーションがサーブレット3.0またはそれ以前を使用しているかどうかに基づき、web.xml
デプロイメント記述子を使用して、RESTful Webサービス・アプリケーションのサーブレットとのパッケージ化の方法について説明します。
web.xml
ファイルは、アプリケーション・アーカイブのルート・ディレクトリのWEB-INF
ディレクトリにあります。web.xml
デプロイメント記述子の詳細は、Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発のweb.xmlデプロイメント記述子の要素を参照してください。
RESTful Webサービス・アプリケーションのサーブレット3.0とのパッケージ化方法
RESTful Webサービス・アプリケーションをサーブレット3.0とパッケージ化するには、web.xml
デプロイメント記述子を更新し、次の項に定義された要素を定義します。要素は、javax.ws.rs.core.Application
を拡張するクラスをパッケージに含めるかどうかで変わります。
-
アプリケーション・サブクラスのあるweb.xmlを使用したRESTful Webサービス・アプリケーションのパッケージ化
-
アプリケーション・サブクラスのないweb.xmlを使用したRESTful Webサービス・アプリケーションのパッケージ化
要素の詳細は、Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発のサーブレットを参照してください。
アプリケーション・サブクラスのあるweb.xmlを使用したRESTful Webサービス・アプリケーションのパッケージ化
javax.ws.rs.core.Application
を拡張するクラスがweb.xml
とともにパッケージ化されている場合、要素を表4-2に示すように定義します。たとえば、例4-2を参照してください。
表4-2 アプリケーション・サブクラスのあるweb.xmlを使用したRESTful Webサービス・アプリケーションのパッケージ化
要素 | 説明 |
---|---|
|
この要素を、 |
|
必要ありません。 |
|
必要ありません。 |
|
サーブレットにマップされる基底URIパターンとして設定します。 指定されない場合、次の優先順位に従って、次の値のいずれかが使用されます。
この情報がリソースの基底URIで使用される方法の詳細は、「実行時の処理: 基底URIの構成方法」を参照してください |
次の例では、javax.ws.rs.core.Application
を拡張するクラスがweb.xml
とパッケージ化される場合に、web.xml
ファイルを更新する方法を示します。
例4-2 アプリケーション・サブクラスがパッケージ内にある場合のサーブレット3.0用web.xmlの更新
<web-app> <servlet> <servlet-name>org.foo.rest.MyApplication</servlet-name> </servlet> ... <servlet-mapping> <servlet-name>org.foo.rest.MyApplication</servlet-name> <url-pattern>/resources</url-pattern> </servlet-mapping> ... </web-app>
アプリケーション・サブクラスのないweb.xmlを使用したRESTful Webサービス・アプリケーションのパッケージ化
javax.ws.rs.core.Application
を拡張するクラスがweb.xmlとともにパッケージ化されていない
場合は、表4-3に示すように要素を定義します。
ノート:
このシナリオでは、複数のRESTful Webサービス・アプリケーションはサポートされません。
表4-3 アプリケーション・サブクラスのないweb.xmlを使用したRESTful Webサービス・アプリケーションのパッケージ化
要素 | 説明 |
---|---|
|
この要素を対象のサーブレット名に設定します。 |
|
この要素を、すべてのWebリクエストをJerseyサーブレットに委任するように、 |
|
必要ありません。 |
|
サーブレットにマップされる基底URIパターンとして設定します。指定しない場合、この値のデフォルトは この情報がリソースの基底URIで使用される方法の詳細は、「実行時の処理: 基底URIの構成方法」を参照してください |
次の例では、javax.ws.rs.core.Application
を拡張するクラスがweb.xml
とパッケージ化されない場合、web.xml
ファイルを更新する方法を示します。
ノート:
JAX-RS仕様では、『Jersey 2.22 User Guide』の説明に従って、servlet-nameをjavax.ws.rs.Application
に設定するには、サーブレット3.0のアプリケーション・サブクラスを含まないweb.xml
を使用したRESTful Webサービス・アプリケーションが必要です。このセクションに定義されているパッケージ化方法は、JAX-RS仕様ではサポートされていません。
例4-3 アプリケーション・サブクラスがパッケージ内にない場合のサーブレット3.0用web.xmlの更新
<web-app> <servlet> <servlet-name>Jersey Web Application</servlet-name> <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class> </servlet> <servlet-mapping> <servlet-name>Jersey Web Application</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> </web-app>
RESTful Webサービス・アプリケーションの3.0以前のサーブレットとのパッケージ化方法
表4-4に、RESTful Webサービス・アプリケーションを3.0以前のサーブレットとパッケージ化するために、web.xml
デプロイメント記述子で更新する要素を示します。
表4-4 RESTful Webサービス・アプリケーションの3.0以前のサーブレットとのパッケージ化
要素 | 説明 |
---|---|
|
この要素を対象のサーブレット名に設定します。 |
|
この要素を、すべてのWebリクエストをJerseyサーブレットに委任するように、 |
|
この要素を、 <init-param>
<param-name>
javax.ws.rs.Application
</param-name>
<param-value>
ApplicationSubclassName
</param-value>
</init-param>
あるいは、次のようにして、リソースおよびプロバイダをスキャンするパッケージを指定できます。 <init-param>
<param-name>
jersey.config.server.provider.packages
</param-name>
<param-value>
project1
</param-value>
</init-param>
<init-param>
<param-name>
jersey.config.server.provider.scanning.recursive
</param-name>
<param-value>
false
</param-value>
</init-param>
|
|
サーブレットにマップされる基底URIパターンとして設定します。 指定されない場合、次の優先順位に従って、次の値のいずれかが使用されます。
この情報がリソースの基底URIで使用される方法の詳細は、「実行時の処理: 基底URIの構成方法」を参照してください |
次の例では、javax.ws.rs.core.Application
を拡張するクラスがweb.xml
とパッケージ化されない場合、web.xml
ファイルを更新する方法を示します。
例4-4 3.0以前のサーブレット用web.xmlの更新
<web-app> <servlet> <servlet-name>Jersey Web Application</servlet-name> <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class> <init-param> <param-name>jersey.config.server.provider.packages</param-name> <param-value>org.foo.myresources,org.bar.otherresources</param-value> </init-param> <init-param> <param-name>jersey.config.server.provider.scanning.recursive</param-name> <param-value>false</param-value> </init-param> ... </servlet> ... </web-app>
デフォルト・リソースとしてのパッケージ化
デフォルトでは、WebLogic ServerによってデフォルトのRESTful Webサービス・アプリケーションのコンテキスト・パスresources
が定義されます。デフォルトのRESTful Webサービス・アプリケーションのコンテキスト・パスは、次に該当する場合に使用されます。
-
web.xml
デプロイメント記述子を更新してサーブレットのマッピングを含めなかった場合(サーブレットとのパッケージ化を参照)。 -
@ApplicationPath
アノテーションがjavax.ws.rs.core.Application
サブクラスで定義されていない場合(アプリケーション・サブクラスとのパッケージ化を参照)。
ノート:
サーブレットがすでにデフォルトのコンテキスト・パスに登録されている場合、警告が発行されます。
たとえば、RESTful Webサービス・アプリケーションのルート・リソース・クラスの相対URIが@Path('/helloworld')
と定義され、デフォルトのRESTful Webサービス・アプリケーションのコンテキスト・パスが使用されている場合、RESTful Webサービス・アプリケーションのリソースは次のURIで入手できます。
http://<host>:<port>/<contextPath>/resources/helloworld