Should I make external API calls in django model managers
up vote
0
down vote
favorite
I have local django models that mirror some external service's entities. So basically when I create a local object, I start with making post requests to the service and then fill fields of the local object with the data from response and save it.
Is it a good idea to put external api calls to model manager in order to abstract the logic for views and tests? Or is there a better approach?
What I would like to achieve is to avoid duplicate logic everywhere in the codebase.
django api model
add a comment |
up vote
0
down vote
favorite
I have local django models that mirror some external service's entities. So basically when I create a local object, I start with making post requests to the service and then fill fields of the local object with the data from response and save it.
Is it a good idea to put external api calls to model manager in order to abstract the logic for views and tests? Or is there a better approach?
What I would like to achieve is to avoid duplicate logic everywhere in the codebase.
django api model
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have local django models that mirror some external service's entities. So basically when I create a local object, I start with making post requests to the service and then fill fields of the local object with the data from response and save it.
Is it a good idea to put external api calls to model manager in order to abstract the logic for views and tests? Or is there a better approach?
What I would like to achieve is to avoid duplicate logic everywhere in the codebase.
django api model
I have local django models that mirror some external service's entities. So basically when I create a local object, I start with making post requests to the service and then fill fields of the local object with the data from response and save it.
Is it a good idea to put external api calls to model manager in order to abstract the logic for views and tests? Or is there a better approach?
What I would like to achieve is to avoid duplicate logic everywhere in the codebase.
django api model
django api model
asked Nov 19 at 13:56
Den Kasyanov
206
206
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
Model manager seems to be a nice idea. But maybe its better to put those logic for external api calls in a separate class. For example:
class ExternalApiService(object):
model = ModelName
def create_object(self, **kwargs):
# create model object
self.model.objects.create(**kwargs)
def call_external_api(self):
# returns json response from API
def process_api_response(self, json_response):
# process response
def get_latest_object(self):
# get latest object
def get_object(self, pk):
# get object
And use them in views.
service = ExternalApiService()
class SomeView(ListView):
queryset = service.get_queryset()
def get_context_data(self, *args, **kwargs):
context = super(SomeView, self).get_context_data(*args, **kwargs)
context['something_specific'] = service.get_latest_object()
return context
Advantage of having this layering is to separate models and views from business logic and external services. Also gives more flexibility, because you can access external api from the Service Class Object without having access to the Model or dependency on the Model.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
Model manager seems to be a nice idea. But maybe its better to put those logic for external api calls in a separate class. For example:
class ExternalApiService(object):
model = ModelName
def create_object(self, **kwargs):
# create model object
self.model.objects.create(**kwargs)
def call_external_api(self):
# returns json response from API
def process_api_response(self, json_response):
# process response
def get_latest_object(self):
# get latest object
def get_object(self, pk):
# get object
And use them in views.
service = ExternalApiService()
class SomeView(ListView):
queryset = service.get_queryset()
def get_context_data(self, *args, **kwargs):
context = super(SomeView, self).get_context_data(*args, **kwargs)
context['something_specific'] = service.get_latest_object()
return context
Advantage of having this layering is to separate models and views from business logic and external services. Also gives more flexibility, because you can access external api from the Service Class Object without having access to the Model or dependency on the Model.
add a comment |
up vote
3
down vote
Model manager seems to be a nice idea. But maybe its better to put those logic for external api calls in a separate class. For example:
class ExternalApiService(object):
model = ModelName
def create_object(self, **kwargs):
# create model object
self.model.objects.create(**kwargs)
def call_external_api(self):
# returns json response from API
def process_api_response(self, json_response):
# process response
def get_latest_object(self):
# get latest object
def get_object(self, pk):
# get object
And use them in views.
service = ExternalApiService()
class SomeView(ListView):
queryset = service.get_queryset()
def get_context_data(self, *args, **kwargs):
context = super(SomeView, self).get_context_data(*args, **kwargs)
context['something_specific'] = service.get_latest_object()
return context
Advantage of having this layering is to separate models and views from business logic and external services. Also gives more flexibility, because you can access external api from the Service Class Object without having access to the Model or dependency on the Model.
add a comment |
up vote
3
down vote
up vote
3
down vote
Model manager seems to be a nice idea. But maybe its better to put those logic for external api calls in a separate class. For example:
class ExternalApiService(object):
model = ModelName
def create_object(self, **kwargs):
# create model object
self.model.objects.create(**kwargs)
def call_external_api(self):
# returns json response from API
def process_api_response(self, json_response):
# process response
def get_latest_object(self):
# get latest object
def get_object(self, pk):
# get object
And use them in views.
service = ExternalApiService()
class SomeView(ListView):
queryset = service.get_queryset()
def get_context_data(self, *args, **kwargs):
context = super(SomeView, self).get_context_data(*args, **kwargs)
context['something_specific'] = service.get_latest_object()
return context
Advantage of having this layering is to separate models and views from business logic and external services. Also gives more flexibility, because you can access external api from the Service Class Object without having access to the Model or dependency on the Model.
Model manager seems to be a nice idea. But maybe its better to put those logic for external api calls in a separate class. For example:
class ExternalApiService(object):
model = ModelName
def create_object(self, **kwargs):
# create model object
self.model.objects.create(**kwargs)
def call_external_api(self):
# returns json response from API
def process_api_response(self, json_response):
# process response
def get_latest_object(self):
# get latest object
def get_object(self, pk):
# get object
And use them in views.
service = ExternalApiService()
class SomeView(ListView):
queryset = service.get_queryset()
def get_context_data(self, *args, **kwargs):
context = super(SomeView, self).get_context_data(*args, **kwargs)
context['something_specific'] = service.get_latest_object()
return context
Advantage of having this layering is to separate models and views from business logic and external services. Also gives more flexibility, because you can access external api from the Service Class Object without having access to the Model or dependency on the Model.
edited Nov 19 at 15:31
Bruno A.
48647
48647
answered Nov 19 at 14:06
ruddra
10.7k32647
10.7k32647
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53376186%2fshould-i-make-external-api-calls-in-django-model-managers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown