Jak optymalnie przekazywać dane z zewnętrznych API do Django aby potem je wykorzystać na stronie

pytanie zadane 10 lutego w Python przez Dawid89 Obywatel (1,120 p.)

Część,

Chciałbym pobrać z zewnętrznego API jakieś dane a następnie wyświetlić na stronie a drugą część najpierw w jakiś sposób modyfikować i potem również wyświetlić na stronie. Oczywiście musiałoby to również znaleźć się w moim API po przetworzeniu. Może ktoś pomóc jak to wykonać aby miało ręce i nogi? Ja to widzę tak:

1. Robię plik ze skryptem gdzie jest requests.

2. W modelach robię model dla tych danych które chce pobierać i przetwarzać.

3. No i tutaj już nie wiem jak to przekazać do modelu. Jak to co pobieram za pomocą requesta zapisywać w bazie?

4. Jak przekazać do widoków oraz serializować dane dla których robię request ale nie chce ich przetwarzać tylko od razu wyświetlić na stronie ?

Czy ktoś doradzi? Ewentualnie wskaże gdzie mogę znaleźć przykład takiego projektu na Githubie albo tutorial do poczytania?

1 odpowiedź

odpowiedź 10 lutego przez adrian17 Ekspert (344,860 p.)
wybrane 12 lutego przez Dawid89

Najlepsza

3. No i tutaj już nie wiem jak to przekazać do modelu. Jak to co pobieram za pomocą requesta zapisywać w bazie?

Żeby skrypt miał dostęp do modeli, najprościej żeby ten skrypt był odpalany jako komenda z Django, to znaczy:

https://docs.djangoproject.com/en/3.2/howto/custom-management-commands/

Wtedy w skrypcie możesz normalnie łączyć wszystko

data = requests.get("...").json()
SomeModel.objects.create(a=data.a, b=data.b)

I odpalać go z

python manage.py mojakomenda

4. Jak przekazać do widoków oraz serializować dane dla których robię request ale nie chce ich przetwarzać tylko od razu wyświetlić na stronie ?

A tego pytania nie rozumiem. Czy chcesz żeby ten request dział się osobno w dowolnym czasie? Czy w czasie odpowiadania na zapytanie HTTP? Możesz jakoś konkretniej? Bo nie wiem o jakiej serializacji mówisz.

komentarz 10 lutego przez Dawid89 Obywatel (1,120 p.)
edycja 10 lutego przez Dawid89

Żeby skrypt miał dostęp do modeli, najprościej żeby ten skrypt był odpalany jako komenda z Django, to znaczy:

https://docs.djangoproject.com/en/3.2/howto/custom-management-commands/

Wtedy w skrypcie możesz normalnie łączyć wszystko

A można jakoś przez panel admina to zrobić? Chodziłoby mi bardziej o to żebym mógł wszystko co potrzebuje wpisać w panelu a na froncie będzie pętla dla wyświetlania obiektów. W sensie dodałbym sobie pola w modelu np. kurs waluty, tam wpisywałbym co trzeba przez panel admina a po zapisie request pobierze co trzeba i zapisze w bazie. Teraz pomyślałem, że może sygnał tutaj się sprawdzi? Znalazłem też coś takiego jak JSONField (https://docs.djangoproject.com/en/3.1/ref/contrib/postgres/fields/#jsonfield )

A tego pytania nie rozumiem. Czy chcesz żeby ten request dział się osobno w dowolnym czasie? Czy w czasie odpowiadania na zapytanie HTTP? Możesz jakoś konkretniej? Bo nie wiem o jakiej serializacji mówisz.

No tutaj te 2 opcje wchodzą w grę. Ogólnie chodzi o to żeby wyświetlić aktualny kurs danej waluty więc ten request musi się jakoś zapętlać co x czasu i wyświetlać zaktualizowany w dowolnym czasie.

Ale też chcę umieścić formularz do wyświetlenia konkretnej informacji typu: user wpisuje date i dostaje kurs z tego konkretnego dnia.

komentarz 10 lutego przez adrian17 Ekspert (344,860 p.)

A można jakoś przez panel admina to zrobić?

Też można, choć tego się tak łatwo nie rozszerza. Często ludzie prędzej robią osobny panel admina w ramach strony ;)

Ogólnie chodzi o to żeby wyświetlić aktualny kurs danej waluty więc ten request musi się jakoś zapętlać co x czasu

No, to to brzmi jak jakiś cron (lub odpowiednik) odpalający komendę dodającą nowy wynik do bazy danych co X czasu.

Ale też chcę umieścić formularz do wyświetlenia konkretnej informacji typu: user wpisuje date i dostaje kurs z tego konkretnego dnia.

W sensie... jeśli API z którym gadasz requests'em możesz pytać o stare daty, to to rób ;D Alternatywnie możesz (pewnie i tak powinieneś) trzymać wyniki zapisane w bazie i je wczytywać?

komentarz 11 lutego przez Dawid89 Obywatel (1,120 p.)

W sensie... jeśli API z którym gadasz requests'em możesz pytać o stare daty, to to rób ;D Alternatywnie możesz (pewnie i tak powinieneś) trzymać wyniki zapisane w bazie i je wczytywać?

Może to być zrobione w taki sposób?

skrypt:

def get_ticket(ticket):

    parameters = {
        'ticker':ticket,
        'active':'true',
        'apiKey': '***'
    }
    headers = {
        'content-type': 'application/json',
        'content-encoding':	'gzip',
        'User-Agent': 'Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.164 Mobile Safari/537.36'
        }

    r = requests.get('https://api.polygon.io/v3/reference/tickers', params=parameters, headers=headers)

    data = r.json()
    return data['results'][0]['name']

views:

def home(request):
    ticket = request.GET.get('ticket')

    if ticket:
        single_ticket = get_ticket(ticket)
    else:
        single_ticket = None

    context = {
        'ticket':single_ticket
    }

    return render(request, 'home.html', context)

home:

<body>
    <form action="" method="get">
        <input type="text" name="ticket">
        <button type="submit" value="szukaj">szukaj</button>
    </form>
    {% if ticket %}{{ticket}}{% endif %}
</body>

komentarz 11 lutego przez adrian17 Ekspert (344,860 p.)

Na oko wygląda OK. Zakładam że testowałeś i działa? :D

Tylko jedna uwaga, że

    headers = {
        'content-type': 'application/json',
        'content-encoding': 'gzip',
        'User-Agent': 'Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.164 Mobile Safari/537.36'
        }

na oko, w typowym API, te headery w ogóle nie powinny być potrzebne i kod powinien zadziałać bez `headers=headers`.

BTW, ticket -> ticker? :D

komentarz 11 lutego przez Dawid89 Obywatel (1,120 p.)

Na oko wygląda OK. Zakładam że testowałeś i działa? :D

Tak, działa. Nie wiem tylko jak z wydajnością takiego rozwiązania jeżeli tych requestów zacznie przybywać. I wolałem się upewnić, że w views może to tak wyglądać.