design patterns - Designing Python client for multiple different REST APIs -


we develop python wrapper rest api in our platform. right now, platform has 12 different apis, unrelated in function, don't share same base url, , have different authentication methods. related in sense, part of platform. @ moment developing client single api (out of list of twelve), it's remaining apis have python wrapper in future.

to avoid headeaches down road, we've been discussing structure of package , can't 100% agree on structure

one point of view creating (ultimately) 12 different packages, 1 each api. (names non-pythonic sake of clarity)

$ pip install platform_apiclient_foo  $ pip install platform_apiclient_bar $ pip install platform_apiclient_spam ... 

and in code use like:

from platform_apiclient_foo import clientfoo platform_apiclient_bar import bar 

the argument not have common function , should separated.

the second point of view creating 1 package encompassing current , possible future apis, require install single package

$ pip install platform_apiclient 

for each api, there separate module, leading usage

from platform_apiclient.spam import spamclient platform_apiclient.foo import fooclient 

i fan of second approach seems easier maintain (from devs perspective), easier use (from user's perspective) , might benefit @ least code reuse. argument against second approach might how take account different versions of rest apis (altough might solvable argument when instantiating client class).

which of 2 desgins seems more appropriate? there other ways solve this? missing arguments pro/against of two?


Comments

Popular posts from this blog

php - Vagrant up error - Uncaught Reflection Exception: Class DOMDocument does not exist -

vue.js - Create hooks for automated testing -

Add new key value to json node in java -