Difference between revisions of "Trove/extensionsrefactor"
< Trove
(→Why do it this way?) |
m (colonectomy) |
||
| Line 1: | Line 1: | ||
| − | == Dynamic route proposal | + | == Dynamic route proposal == |
| − | === Changes | + | === Changes === |
*Remove existing extensions and move routes mapped into base API app. Ex: instances/<instance_id>/users | *Remove existing extensions and move routes mapped into base API app. Ex: instances/<instance_id>/users | ||
*Add code to inspect instance_id and map it to an instance type.. Redis Postgres MySQL etc. | *Add code to inspect instance_id and map it to an instance type.. Redis Postgres MySQL etc. | ||
| Line 15: | Line 15: | ||
*I like this one more =P. | *I like this one more =P. | ||
| − | === Cons | + | === Cons === |
*Less explicit then using database specific prefixes. | *Less explicit then using database specific prefixes. | ||
| − | == Alternative Solutions | + | == Alternative Solutions == |
| − | == Use a db specific routing methodology | + | == Use a db specific routing methodology == |
| − | === Changes | + | === Changes === |
*Remove existing extensions and move routes mapped into base API app. Ex instances/<instance_id>/<db_type>/users | *Remove existing extensions and move routes mapped into base API app. Ex instances/<instance_id>/<db_type>/users | ||
*Add code to inspect instance_id and verify it's instance type.. Redis Postgres MySQL etc. | *Add code to inspect instance_id and verify it's instance type.. Redis Postgres MySQL etc. | ||
| Line 29: | Line 29: | ||
*Contract is explicit for each URI rather than explicit for database type. | *Contract is explicit for each URI rather than explicit for database type. | ||
*hub_cap is all about this one! | *hub_cap is all about this one! | ||
| − | === Cons | + | === Cons === |
*Potential api version change. | *Potential api version change. | ||
*Wonky for Users only using one DB type. The solution to that edge case is to implement a default type for instances/<instance_id> and that is the same as supporting dynamic type resolution essentially. | *Wonky for Users only using one DB type. The solution to that edge case is to implement a default type for instances/<instance_id> and that is the same as supporting dynamic type resolution essentially. | ||
| Line 35: | Line 35: | ||
*Need to know what type db is in order to know what uri to post to. | *Need to know what type db is in order to know what uri to post to. | ||
| − | == Client Examples | + | == Client Examples == |
=== Client interaction flow with dynamic type resolution for user add example === | === Client interaction flow with dynamic type resolution for user add example === | ||
*Determine type from instances listing. | *Determine type from instances listing. | ||
Revision as of 12:40, 24 July 2013
Contents
Dynamic route proposal
Changes
- Remove existing extensions and move routes mapped into base API app. Ex: instances/<instance_id>/users
- Add code to inspect instance_id and map it to an instance type.. Redis Postgres MySQL etc.
- Have "proxy" route dynamically load a service for each database type either with importlib or stevedore whatever.
- Have the route dynamically accept requests for special edge cases for differing database engines. Ex: Default database for postgres on user create while MySQL does not use one.
Why do it this way?
- Does not change existing API spec. No need to version the API.
- Less cruft in API vs having prefix based user or backup requests. Ex /instances/<instance_id>/mysql/users.
- Generate plugins more quickly and never have routing collisions for new database types. As the request body expected is based off of database type not route.
- Allows for multiple versions or forks of different Database engines more easily. Ex: Allow multiple versions of a Database engine that have differing user create requirements.. (Can't think of anything that exactly matches that scenario so maybe this is a bad example. However, it does allow for differing versions of one database application.)
- Allows the interface for users who only want to support one DB engine to be simplified. Ex: No database type specific URI prefix.
- Allows the base URI mappings to be the same for all databases that have a common type. Ex: users, backups etc.
- Probably less code overall depending on how the prefix specific routes could be added.
- I like this one more =P.
Cons
- Less explicit then using database specific prefixes.
Alternative Solutions
Use a db specific routing methodology
Changes
- Remove existing extensions and move routes mapped into base API app. Ex instances/<instance_id>/<db_type>/users
- Add code to inspect instance_id and verify it's instance type.. Redis Postgres MySQL etc.
- Have "proxy" route dynamically load a service for each database type either with importlib or stevedore whatever.
- Have the route accept requests for differing database engines. Ex. Default database for postgres on user create while MySQL does not use one.
Why do it this way?
- More explicit than dynamic type mapping.
- Might be easier to write docs as each URI is explicit rather than implicit based off of its type.
- Contract is explicit for each URI rather than explicit for database type.
- hub_cap is all about this one!
Cons
- Potential api version change.
- Wonky for Users only using one DB type. The solution to that edge case is to implement a default type for instances/<instance_id> and that is the same as supporting dynamic type resolution essentially.
- Lots of routes to mange depending on how we decide to implement the routing.
- Need to know what type db is in order to know what uri to post to.
Client Examples
Client interaction flow with dynamic type resolution for user add example
- Determine type from instances listing.
- post to instances/<instance_id>/users with db specific body.
- validate input.
- 404 if db does not have concept of users.
- 2** if all is well
Client interaction flow with static db routes for user add example
- Determine type from instance listing.
- post to instances/<instance_id>/<db_type>/users with db specific body.
- validate input.
- 404 if db does not have concept of users.
- 2** if all is well.
