プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Server RESTful Webサービスの開発と保護
12c (12.2.1.3.0)
E90341-02
目次へ移動
目次
前
前 		次
次

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サービス・アプリケーションの構築

Apache Ant、Mavenなどのコンパイル・ツールやOracle JDeveloperなどの好みのIDEを使用して、RESTful Webサービス・アプリケーションおよびクライアント・アプリケーションを構築できます。Oracle WebLogic Serverアプリケーションの開発で、Overview of WebLogic Serverアプリケーションの開発を参照してください。JDeveloperの詳細は、Oracle JDeveloperによるアプリケーションの開発のJavaプロジェクトのビルドを参照してください。

RESTful Webサービス・アプリケーションのパッケージ化

すべてのRESTful Webサービス・アプリケーションはWebアプリケーションの一部としてパッケージ化される必要があります。WebサービスがEJBとして実装される場合、WAR内にパッケージ化およびデプロイされる必要があります。

表4-1に、RESTful Webサービス・アプリケーションに使用できる特定のパッケージ化オプションの概要を示します。

表4-1 RESTful Webサービス・アプリケーションのパッケージ化オプション

パッケージ化オプション 説明

アプリケーション・サブクラス

javax.ws.rs.core.Applicationを拡張するクラスを定義して、RESTful Webサービス・アプリケーション・デプロイメントのコンポーネントを定義し、追加のメタデータを提供します。javax.ws.rs.ApplicationPathアノテーションをサブクラスに追加して、サーブレットのコンテキスト・パスを構成できます。

アプリケーション・サブクラスとのパッケージ化を参照してください。

サーブレット

web.xmlデプロイメント記述子を更新して、サーブレットおよびマッピングを構成します。使用されるメソッドはWebアプリケーションがサーブレット3.0またはそれ以前を使用しているかどうかにより異なります。サーブレットとのパッケージ化を参照してください。

デフォルト・リソース

前述のオプションのいずれかを使用して、構成内にサーブレットのコンテキスト・パスを構成しない場合、WebLogic ServerによってデフォルトのRESTful Webサービス・アプリケーション・サーブレットのコンテキスト・パスresourcesが提供されます。デフォルト・リソースとしてのパッケージ化を参照してください。

アプリケーション・サブクラスとのパッケージ化

このパッケージ化シナリオでは、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を使用して、指定されたクラスパスまたは一連のパッケージ名がないかルート・リソースおよびプロバイダ・クラスをスキャンします。

サーブレットとのパッケージ化

次の項では、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を拡張するクラスをパッケージに含めるかどうかで変わります。

要素の詳細は、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サービス・アプリケーションのパッケージ化

要素 説明

<servlet-name>

この要素を、javax.ws.rs.core.Applicationを拡張するクラスの完全修飾名に設定します。複数のサーブレット・エンティティを指定して、複数のApplicationサブクラス名を定義することもできます。

<servlet-class>

必要ありません。

<init-param>

必要ありません。

<servlet-mapping>

サーブレットにマップされる基底URIパターンとして設定します。

指定されない場合、次の優先順位に従って、次の値のいずれかが使用されます。

<servlet-mapping>と@ApplicationPathの両方が指定されている場合、<servlet-mapping>が優先されます。

この情報がリソースの基底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サービス・アプリケーションのパッケージ化

要素 説明

<servlet-name>

この要素を対象のサーブレット名に設定します。

<servlet-class>

この要素を、すべてのWebリクエストをJerseyサーブレットに委任するように、org.glassfish.jersey.servlet.ServletContainerに設定します。

<init-param>

必要ありません。

<servlet-mapping>

サーブレットにマップされる基底URIパターンとして設定します。指定しない場合、この値のデフォルトはresourcesです。デフォルト・リソースとしてのパッケージ化を参照してください。

この情報がリソースの基底URIで使用される方法の詳細は、「実行時の処理: 基底URIの構成方法」を参照してください

次の例では、javax.ws.rs.core.Applicationを拡張するクラスがweb.xmlとパッケージ化されない場合、web.xmlファイルを更新する方法を示します。

例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以前のサーブレットとのパッケージ化

要素 説明

<servlet-name>

この要素を対象のサーブレット名に設定します。

<servlet-class>

この要素を、すべてのWebリクエストをJerseyサーブレットに委任するように、org.glassfish.jersey.servlet.ServletContainerに設定します。

<init-param>

この要素を、javax.ws.rs.core.Applicationを拡張するクラスを定義するように設定します。

<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>

<servlet-mapping>

サーブレットにマップされる基底URIパターンとして設定します。

指定されない場合、次の優先順位に従って、次の値のいずれかが使用されます。

<servlet-mapping>と@ApplicationPathの両方が指定されている場合、<servlet-mapping>が優先されます。

この情報がリソースの基底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サービス・アプリケーションのコンテキスト・パスは、次に該当する場合に使用されます。

注意:

サーブレットがすでにデフォルトのコンテキスト・パスに登録されている場合、警告が発行されます。

たとえば、RESTful Webサービス・アプリケーションのルート・リソース・クラスの相対URIが@Path('/helloworld')と定義され、デフォルトのRESTful Webサービス・アプリケーションのコンテキスト・パスが使用されている場合、RESTful Webサービス・アプリケーションのリソースは次のURIで入手できます。

http://<host>:<port>/<contextPath>/resources/helloworld

RESTful Webサービス・アプリケーションのデプロイ

アプリケーション・デプロイメントとは、WebLogicドメインでアプリケーションまたはモジュールをクライアント・リクエストの処理に使用できるようにするプロセスを指します。Webアプリケーションのデプロイの詳細は、Oracle WebLogic ServerへのアプリケーションのデプロイのWebLogic Serverデプロイメントの理解を参照してください。
前
前 		次
次
目次へ移動
目次