与えられたタイプの特定のレコードのフィールド値の動的/構成可能なセットを返す、データベースから。 Webサービスはベンダーのものですが、私たちはAPI定義/設計を管理しています。目標はこのAPIを定義することです。一般的なWebサービスAPIを定義して、DBからのフィールドの動的セットを取り除く必要があります
背景：
私たちは、SaaSのベンダーによってホストされているDBを持っています。 DBには、申請者、アプリケーション、ロケーションなどのさまざまな（「タイプ」）テーブルが含まれています。データを取得するために呼び出すことができるベンダーのWebサービスが公開されています。 WebサービスのAPIを更新しているベンダーによってサポートされる新しい一連の要件があります。
要件：ストアの
1.Mediumとフィールドの設定可能なリストを取得： 我々は（特定のレコードに対して）DBから取得するフィールドを格納する方法を考え出すしなければなりません設定媒体では、この媒体には、それぞれに対応するフィールドを持つデータ型のリストが含まれます。このメディアは、Webサービスから特定のレコードに対して取得されるものを駆動するものです。
例： configメディアには、ID、FirstName、LastNameのフィールドを持つ「Applicant」データタイプを含めることができます。これは、「申請者」タイプの記録を取り出すときにのみ、これらの3つのフィールドを尋ねることを意味します。この設定可能なデータはいつでも変更/編集できます。
2.「一般的なWebサービスAPI」フィールドだけを取得する第二の要件は、フィールドの上で設定可能なリストと連携して動作する汎用的なAPIを構築することである を指定しました。レコードID、データ型、および動的なフィールドセット（設定データごと）をとる「汎用的な方法」で、ベンダーのWebサービスインターフェイスを呼び出す必要があります。 「汎用」とは、ベンダーのWebサービスが実行時に取得するフィールドのみを認識することを意味します。つまり、WebサービスAPIに影響を与えずに、設定ソース（フィールドまたはデータ型のいずれか）を変更することができます。
Qsが/思考は以下のとおりです。
a）の設定ストレージ： は、我々は、configファイル、DB、またはWebサービスで私たちの最後に設定を管理します。これを行うより一般的な方法がありますか？このシナリオでは、（指定されたデータ型のフィールドのリストを公開する）Webサービスも理にかなっていますか？
b）は、「一般的な」Webサービスを作る：「それぞれが」与えられたレコードのデータを取得するために、Webサービスに呼び出す
--on、我々は入力のparamとして引っ張ってフィールドの動的なセットを送信 - オブジェクトまたはリストなどとすることもできます。
- 「each」コールのリストを送信する代わりに、レコードIDとタイプをWebサービスに送信し、Webサービスがプルするフィールドを検索しますWebサービスから