My clients use one of the following when they sign up for my application:
- Foo API (requires a "auth_key", "password", "email")
- Acme API (requires a "secure_code", "username", "password")
- Bar API (requires a "xyz_code", "pass_key")
(fake names, and about 15 more omitted for simplicity)
I would prefer not to have 10-15 tables in my database just for the different API integration options I offer (particularly when they're all for the same thing and they just choose 1 from the whole list).
My solution was this:
Make a api_configuration
table with a column called api_name
which holds a code for a specific API (e.g. "foo_api"
)
Make a table called credentials_attribute
with a foreign key back to api_configuration
, a column called name
, and a column called value
.
Then I build a UI for choosing an API. If they choose Acme API, it'll ask for a "secure_code", "username", and "password", and create a row in credentials_attribute
for each of the name/value pairs.
On my ORM model for api_configuration
I can make a method for looking up credentials_attribute
values based on the current api_name
.
Does this solution feel right, or is there another way you would do it, if you had to model a solution for this problem? Please explain your rationale as well (ie, better for performance, etc)
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…