Flask REST

0

Dzień dobry, od jakiegoś czasu uczę się Pythona. Swoją przygodę zacząłem od front-endu, a teraz chciałem zobaczyć część back-endu.

Przejście przez podstawy podstaw poszło mi w miarę sprawnie z racji tego, iż miałem jakieś podstawy z JS - pętle, listy, podstawy OOP

Zainteresowałem się frameworkiem Flask, doszedłem do wniosku, że na początku lepiej będzie mi zrozumieć web zaczynając od mniejszego frameworka niż od Django. Jestem na etapie RESTa i templatów we Flasku i próbuje zrozumieć jedną rzecz, jak konkretnie działa REST API. No i teraz nasuwa mi się pytanie związane z http requests.

Wysyłam z przeglądarki na end-point "/user/xxx" GET requesta - otrzymuje w odpowiedzi template wyrenderowany z jakimiś danymi usera, wszystko ok - jakiś template.html
Ale teraz zaczynam się zastanawiać jakbym chciał takiego GETa przez aplikacje mobilną wysłać - przecież w odpowiedzi też otrzymam jakiegoś template - czyli plik html, ale w przypadku aplikacji mobilnej chciałbym otrzymać same dane przecież - czyli chyba jakiegoś JSONa. Jak to powinno być rozwiązane?

Czy w praktyce powinno wyglądać to tak, że posiadam (w tym przypadku wszystko robione na localhoscie) odpalony serwer flask na porcie 5000 -> http://127.0.0.1:5000,
a część Front-Endu jest na jakimś drugim serwerze na domyślnym porcie 80: http://127.0.0.1/ i są to dwie oddzielne aplikacje które wymieniają dane? Serwer od Flask nie wysyła żadnych templatów i zwraca lub pobiera tylko jakieś dane JSON, a serwer Front endu przy kliknięci jakiegoś buttona/jakiejś akcji wysyła zapytanie na port :5000 w celu uzyskania danych?

Starająć się zrozumieć REST doszedłem do wniosku, że nie mogę tak używać templatów Flaska gdyż REST opiera się chyba tylko na wymianie danych klient-serwer?

2
Frek napisał(a):

Zainteresowałem się frameworkiem Flask, doszedłem do wniosku, że na początku lepiej będzie mi zrozumieć web zaczynając od mniejszego frameworka niż od Django. Jestem na etapie RESTa i templatów we Flasku i próbuje zrozumieć jedną rzecz, jak konkretnie działa REST API. No i teraz nasuwa mi się pytanie związane z http requests.

Wysyłam z przeglądarki na end-point "/user/xxx" GET requesta - otrzymuje w odpowiedzi template wyrenderowany z jakimiś danymi usera, wszystko ok - jakiś template.html
Ale teraz zaczynam się zastanawiać jakbym chciał takiego GETa przez aplikacje mobilną wysłać - przecież w odpowiedzi też otrzymam jakiegoś template - czyli plik html, ale w przypadku aplikacji mobilnej chciałbym otrzymać same dane przecież - czyli chyba jakiegoś JSONa. Jak to powinno być rozwiązane?

Dlatego właśnie projektując REST API unikaj pomysłów w stylu renderowanie templatek i odsyłanie przez endpoint. Niech REST API udostępnia jedynie dane - np. w postaci wspomnianego JSONa - do skonsumowania przez inne aplikacje np. aplikację webową w przeglądarce komputera czy jakąś aplikację mobilną. Ułatwisz sobie w ten sposób życie.

Czy w praktyce powinno wyglądać to tak, że posiadam (w tym przypadku wszystko robione na localhoscie) odpalony serwer flask na porcie 5000 -> http://127.0.0.1:5000,
a część Front-Endu jest na jakimś drugim serwerze na domyślnym porcie 80: http://127.0.0.1/ i są to dwie oddzielne aplikacje które wymieniają dane? Serwer od Flask nie wysyła żadnych templatów i zwraca lub pobiera tylko jakieś dane JSON, a serwer Front endu przy kliknięci jakiegoś buttona/jakiejś akcji wysyła zapytanie na port :5000 w celu uzyskania danych?

Generalnie tak, możesz postawić aplikację frontową i z niej łączyć się z serwerem, tylko to może się zrobić upierdliwe np. jak będziesz chciał na szybko pokazać komuś swoją aplikację, masz do odpalenia 2 komendy:

$ python run.py # odpalasz serwer Flaskowy, tutaj metodą "na pałę"
$ npm run # odpalasz aplikację JS

Także w pewnym momencie zechcesz pewnie obok REST API wystawić sobie pojedynczy, klasyczny endpoint (zapewne w roocie: "/") który będzie serwował frontend Twojej aplikacji. Poza tym na dłuższą metę aplikacje Flaskowe lepiej serwować jakimś nginx czy gunicorn, bo flaskowy serwer jest raczej biedny i zaleca się używanie go tylko w celach developerskich.

Starająć się zrozumieć REST doszedłem do wniosku, że nie mogę tak używać templatów Flaska gdyż REST opiera się chyba tylko na wymianie danych klient-serwer?

Generalnie REST powstał (przynajmniej tak mi się wydaje) po to, by

  1. odciążyć serwery - w REST nie podtrzymujesz sesji, więc serwer nie musi utrzymywać aż tylu połączeń HTTP.
  2. umożliwić/ułatwić komunikację z serwerem przez inne aplikacje - no umówmy się, jeśli dane są owijane w templatki i upychane w statycznym widoku HTML, to za wiele się już z tym zrobić nie da. Znaczy da się, ale trzeba by te dane scrapować... jaki jest sens?
0

A czy w praktyce, w jakimś stopniu używa się templatów czy raczej mniej popularne? Wiem, że warto poznać sam sposób działania oraz Jinja2 w przypadku template - ale czy skupiać się na tym na dłuższą mete?
Czy w przypadku Django wygląda to podobnie, że oddzielnie działa serwer back-endu, a oddzielnie stoi aplikacja front endu?

Oczywiście wbudowany serwer Flaska był jako przykład - gdyż póki co uczę się stopniowo i wszystko wykonuje na localhoscie

0
Frek napisał(a):

A czy w praktyce, w jakimś stopniu używa się templatów czy raczej mniej popularne? Wiem, że warto poznać sam sposób działania oraz Jinja2 w przypadku template - ale czy skupiać się na tym na dłuższą mete?

Nie wiem, na ile powszechnie się używa i czy w ogóle. W projekcie, w którym akurat używaliśmy Flask mieliśmy na froncie Vue.js i templatki Jinja2 nie były nam zbytnio potrzebne do szczęścia. Podejrzewam, że to może być dość powszechne podejście - Jinja2 przydaje się do renderowania widoków dla konkretnych danych np. masz listę gości hotelu i korzystając z szablonu możesz sobie taką listę wygenerować. Korzystając np. z Vue czy innego Reacta nie potrzebujesz tego, bo możesz zaciągnąć sobie dane z API i wygenerować to dynamicznie, w międzyczasie pokazać kręcioła żeby user widział, że aplikacja myśli a nie się zawiesiła itp. itd.

Ale ja front słusznie omijam szerokim łukiem, nie pytaj mnie o szczegóły ;)

Czy w przypadku Django wygląda to podobnie, że oddzielnie działa serwer back-endu, a oddzielnie stoi aplikacja front endu?

Tak jak już Ci pisałem, na dłuższą metę wygodniej jest wrzucić zasoby frontu do jakiegoś /static i pozwolić serwerowi backendu to serwować, zamiast stawiać kolejny. Tak się da we Flasku, tak się da w Springu, w ASP.NET MVC też się dało (jeśli mnie pamięć nie myli), więc również w Django musi się dać.

Jeśli Twój serwis ma funkcjonować jako samodzielna aplikacja, a REST API wystawiasz tak "przy okazji" (bo Ci wygodniej, bo jeszcze to żenisz z aplikacją mobilną, bo chcesz żeby aplikacja kolegi mogła sięgać do Twoich zasobów przez API... etc) to chyba nie ma co się babrać ze stawianiem osobno serwera dla frontu, a osobno dla backendu. Dwa razy więcej problemów na głowie. Jeśli postawisz REST API, a potem zaczniesz rzeźbić sobie jakąś aplikację webową, która gdzieś tam, kiedyś, czasem, przy okazji sięga do Twojego i innych API - no to tu bym się zastanawiał nad rozbiciem, żeby już sobie w tym istniejącym API nie bruździć ;)

0

No właśnie - przeglądając różne materiały, kursy, video wszędzie poruszany jest temat przede wszystkim templatów . Zaczął mnie intrygować ten temat w przypadku takich frameworków jak React czy wyżej wspomniane Vue.js - jak to działa skoro wszystko napisane jest w JS. Zasoby typu static są tylko wspominane jako pliki css oraz proste JS'y.
Czyli tak czy inaczej kończy się wszystko na tym, że w tym przypadku Python zwraca/pobiera jedynie dane na konkretny requesty, a dodatkowo dorzuca jakiś html - statyczny z danymi pobranymi przez JS albo przez jakiś front-endowy frameworka i wszystko jest odpalone na jednym serwerze - nie korzystając z template + jinja2, czyli w moim przypadku po prostu na deweloperskim serwerze Flaska, dobrze to rozumiem?

0

Tutaj znalazłem jakiś tutorial dot. stawiania SPA we Flask + Vue właśnie, możesz sobie poczytać

0

No właśnie to jeszcze nie jest poziom na moje początki przygody z programowaniem :). Po prostu zaintrygował mnie ten temat a trudno było znaleźć jakikolwiek materiał oprócz ciągłego powtarzania, że REST:
-Stateless
-Zwraca JSON

1 użytkowników online, w tym zalogowanych: 0, gości: 1