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
Post a Comment