Need to define a generic web service API to handle pull a dynamic set of fields from DB

Need help defining a generic web service API that will return a dynamic/configurable set of field values for a given record of a given "type" from a database. The web service is a vendor's but we have control over the API definition/design. The goal is to define this API.

Background:

We have a DB hosted by a SaaS vendor. The DB contains various ("type") tables eg Applicant, Application, Location, etc. The vendor's exposed a webservice that we can call to retrieve data. We have a new set of requirements that will be supported by the vendor updating their web service's API.

The Requirements:

1.Medium for store and retrieve configurable List of Fields: We have to come up with a way to store the fields to be retrieved from the DB (for a given record) in a config medium -- this medium will contain a list of data types with the associated fields to pull for each. This medium is what drives what's retrieved for a given record from the web service.

Eg. the config medium can contain the "Applicant" data type with the following fields: ID, FirstName, LastName. This means we will only ask for these 3 fields when pull an "applicant" type of record. This configurable data can be changed/edited at any time.

2."Generic Web service API" to retrieve only the fields specified The 2nd requirement is to construct a generic API that works in tandem with the above configurable list of fields. We want to call the vendor's web service interface in a "generic way" that takes开发者_Python百科 a record id, data type, and the dynamic set of fields (per the config data). By "generic", I mean the vendor's web service should only be aware of the fields to retrieve at runtime. This means, we can change the config source (either the fields or the data types) as we see fit without any impact to the web service API.

Qs/Thoughts include:

a) The config storage: We manage the config on our end in a config file, DB, or web service. Is there a better more generic way to do this? Does a web service (that publishes the list of fields for a given datatype) even make sense in this scenario?

b) Making the web service "generic":

--on "each" call to the web service to retrieve data for a given record, we send the dynamic set of fields to pull as an input param --maybe as an object or list, etc.

--instead of send the list on "each" call, we just send the record id and type to the web service and the web service looks up the fields to pull from our web service

The most straightforward way would be to expose the functionality as some kind of RESTful web service. I.e., for applicants you would have /db/applicant/ return a list of all applicants (or applicant IDs), and if 123 is an applicant ID you would retrieve /db/applicant/123. In the simplest way, you would retrieve a JSON object such as

{'first_name':'Joe', 'last_name':'Applicant', 'address':'123 Test Drive'}

Additionally, you could add a parameter that encodes the fields you're interested in, e.g. /db/applicant/123?fields=first_name+last_name.

Using JSON (or XML if you feel it's worth the additional work) has the advantage over CSV or other alternatives in that the set of fields you return is extensible - i.e., if one client needs a shoe_size field, the response for the other one can include it and everything still works.