RESTful Web サービス・プロバイダー・アプリケーションの設計上の考慮事項

このトピックでは、JSON に対して RESTful Web サービス・プロバイダー・アプリケーションを計画および設計する際に考慮する必要のあるいくつかの問題について説明します。

リソース・コレクション

RESTful API の一般的な設計では、リソース・コレクションの取得をサポートする必要があります。例えば、次のようにオブジェクトのセットを返すサービスが存在することがあります。

GET /Services/CustomerDetails?Surname=Cooper

この要求では、姓が "Cooper" であるすべての CustomerDetails オブジェクトに関する情報を返すことが期待されます。個々の CustomerDetails オブジェクトは、次のようなより詳細な URI を使用して返すことができます。

GET /Services/CustomerDetails/Customer27

この例では、Customer27 は特定のカスタマーの 1 次キーです。この 2 番目の照会からの出力は、CustomerDetails オブジェクトのインスタンスになります。最初の照会からの出力は、明確ではありません。CustomerDetails オブジェクトのリストを返すか、または CustomerDetails オブジェクトの URI のリストを戻します (クライアントはこれらを個別に取得していくことができます)。両方の規則は共通です。

CICS でコレクションを実装するために、データ・インスタンスのリストまたは URI のリストのいずれかを記述する JSON スキーマを作成します。サービスを作成し、通常どおりそのサービスを実装できます。この例では、GET メソッドのみを選択して、実装します。以下の例のように、クライアントが大きなデータ・セットで前方および後方にページングできるようにページ編集サービスを実装することを検討できます。

GET
/Services/CustomerDetails?startRecord=200&endRecord=225

CICS で 2 つの URIMAP リソース (および 2 つの WEBSERVICE リソース) を必要とする場合があります。 1 つはコレクションのルート URI 構造をマップし、もう 1 つはインスタンスのワイルドカード URIMAP になります。例えば、次のようになります。

URIMAP1: Path=/Services/CustomerDetails 
WEBSERVICE=CollectionService
URIMAP2: Path=/Services/CustomerDetails/* WEBSERVICE=InstanceService

キャッシュ管理

RESTful アーキテクチャーは、標準 HTTP キャッシュ管理の手法の統合を促進します。このアーキテクチャーにより、GET 要求の結果がネットワークにキャッシュされ、サーバーの負荷が軽減されます。これを実現するためのメカニズムには、GET 要求に対して返されたデータの有効期限日時の設定が含まれます。

CICS におけるアプリケーション制御のキャッシュ有効期限をサポートする汎用目的のメカニズムはありませんが、EXEC CICS WEB WRITE HTTPHEADER API を使用して適切な HTTP ヘッダーを追加するために、パイプライン・ハンドラー・プログラムを作成することができます。アプリケーション・プログラムは、HTTP 要求を受け取るのと同じ CICS 領域でホストされている場合にのみ、類似した動作を実行できます。