W jaki sposób aplikacje pobierają dane z zewnętrznych serwisów i czym jest API?

17 listopada 2018 7 minut czytania

Witam wszystkich w kolejnym odcinku naszej androidowej serii programowania. Dzisiaj chciałbym Wam opowiedzieć o magii, która pozwala na wyświetlanie danych pochodzących z zewnętrznych serwisów w aplikacjach mobilnych.

Zdefiniujmy problem

Wyobraźmy sobie sytuację, w której posiadasz jakiś serwis internetowy z przepisami kulinarnymi. Pewnego dnia postanawiasz stworzyć aplikację, w której użytkownicy będą mieli dostęp do Twoich przepisów. Z pozoru wszystko wydaje się trywialne — po prostu pobieramy przepisy i je wyświetlamy. Jednak to jest właśnie ta cała magia, o której pisałem.

W momencie, gdy otwierasz stronę internetową, to z serwera do Twojej przeglądarki zostaje przesłany kod HTML, który następnie zostaje zamieniony na graficzną interpretację. Teoretycznie moglibyśmy wyświetlić taki kod bezpośrednio w naszej aplikacji, ale stracilibyśmy wszystkie zalety, jakie daje nam pisanie natywnej aplikacji. Moglibyśmy też wziąć kod HTML, wyciągnąć z niego tylko dane dotyczące przepisów i wyświetlić je w naszych natywnych kontrolkach. Takie rozwiązanie jest możliwe do zrealizowania, ale ma kilka poważnych wad. Po pierwsze: musimy przekopywać się przez wiele zagnieżdżonych znaczników HTML i wiedzieć, dokładnie w którym znaczniku znajduje się interesująca nas treść. Po drugie: interesuje nas jedynie sama zawartość przepisów, a nie cała strona HTML — więc będziemy pobierać niepotrzebnie mnóstwo danych i przez to narazimy naszych użytkowników na znaczne zużycie pakietu danych. Po trzecie: przy każdej zmianie struktury naszej strony będziemy musieli również aktualizować logikę aplikacji odpowiedzialną za wyciąganie danych z kodu HTML.

Musi istnieć jakiś prostszy sposób

Być może czytając poprzedni akapit, pomyślałeś sobie, że moglibyśmy przesyłać z serwera tylko najpotrzebniejsze dane bez całej tej HTMLowej otoczki. Gratulacje, to jest właśnie prawidłowe rozwiązanie — tak to się właśnie robi. Tylko tutaj też pojawia się kilka problemów. Musimy ustalić jakiś wzór dla tych danych — tak, abyśmy bez problemu mogli wyszczególnić odpowiednie dane. Jeśli tego nie zrobimy, to przykładowo dwa przepisy mogłyby się zlepić w jeden, lub użytkownik mógłby zobaczyć błędne składniki. Na szczęście pewni mądrzy ludzie znaleźli rozwiązanie tego problemu i zdefiniowali dwa standardy przesyłania danych.

XML i JSON — co to takiego?

O XML mogłeś przeczytać w odcinku poświęconym budowaniu interfejsu użytkownika, jednak tutaj odgrywa on nieco inną rolę. Za pomocą XML możemy przedstawić reprezentację dowolnego obiektu — może to być przepis z naszej bazy. Zwróć uwagę na poniższą grafikę — przedstawia ona dwa przykładowe przepisy zapisane w formacie XML.

Łatwo można wywnioskować, że znaczniki (czyli to, co znajduje się pomiędzy znakiem ’<’ oraz ’>’) definiują nazwy atrybutów, na przykład „dataUtworzenia”. Natomiast to, co znajduje się pomiędzy znacznikami, reprezentuje faktyczną wartość pochodzącą z bazy danych. Pewnie zauważyłeś, że format ten również jest bardzo rozwlekły — pokazany przeze mnie fragment ma dokładnie 1022 znaków. Łatwo można by było pozbyć się kilku znaków, gdybyśmy nie musieli powielać nazwy atrybutu zarówno przed nim, jak i za nim. Na szczęście mam dobrą wiadomość — format ten jest już praktycznie nieużywany i większość serwisów korzysta z następcy XML-a, czyli JSON-a.

Rozwinięcie skrótu JSON jest nieco mylące. Brzmi ono „JavaScript Object Notation”, co możemy przetłumaczyć na „Sposób reprezentacji obiektów JavaScriptowych”. Mimo swojej nazwy format ten jest obsługiwany przez praktycznie wszystkie języki programowania — nie tylko JavaScript. Zobacz poniższy przykład, w którym pokazałem te same przepisy w formacie JSON.

Konstrukcja formatu JSON jest niesamowicie prosta, możemy wyróżnić dwie konstrukcje:

Nawiasy klamrowe ( '{’ oraz ’}’ ) – za ich pomocą reprezentujemy dowolny obiekt. Na przykład obiekt „Składnik” znajdujący się w tablicy „składniki”
Nawiasy kwadratowe ( '[’ oraz ’]’ ) – za ich pomocą reprezentujemy tablicę dowolnych obiektów. Na przykład tablicę o nazwie „przepisy” zawierającą obiekty „Przepis”

Na pierwszy rzut oka widać, że format ten zawiera mniej niepotrzebnych znaczników, co pozwala zmniejszyć rozmiar pobieranych danych z serwera. Przedstawiony wyżej JSON ma tylko 845 znaków, czyli aż 177 mniej niż te same dane przedstawione za pomocą XML-a.

Jak serwer rozpoznaje który format ma nam zwrócić?

Nie wszystkie strony działają jako osobne, zaawansowane aplikacje — w ich przypadku sprawa jest prosta, bo taka strona pobiera JSON-a podobnie jak aplikacja mobilna i przerabia go na graficzną interpretację. W przypadku pozostałych stron tak jak wspomniałem na początku tego artykułu, to serwer zwraca plik HTML wygenerowany na podstawie odpowiednich danych. Skąd serwer może wiedzieć, kiedy powinien zwrócić plik HTML, a kiedy JSON z samymi danymi? Możemy to zrobić na dwa sposoby:

Definiujemy osobne adresy — jest to bardzo często spotykane rozwiązanie. Polega ono na tym, że adresy, z których pobieramy dane w postaci JSON-ów, znajdują się pod innymi adresami www niż normalna strona dostępna dla użytkownika. Przeważnie jest to coś w stylu api.twojastrona.pl
Dodajemy odpowiedni nagłówek — podczas wysyłania zapytania na serwer z Twojej aplikacji, możesz dołączyć dodatkowy nagłówek HTML, który poinformuje serwer, że chciałbyś otrzymać dane w postaci JSON, a nie jako plik HTML.

API — gdzieś to już słyszałem

Pewnie nieraz spotkałeś się ze skrótem API, jego pełne rozwinięcie to Application Programming Interface, co można tłumaczyć jako interfejs programistyczny aplikacji. Termin ten jest używany nie tylko w kontekście komunikacji z serwerem. Jest to nic innego jak ustalony i udokumentowany kontrakt umożliwiający komunikację z naszą aplikacją przez inne programy. Pewnie ten skrót kojarzy Ci się jedynie ze stronami internetowymi, a to dlatego, że głównie tam jest on używany. Każdy z większych serwisów internetowych udostępnia swoje API, umożliwiając tym samym na dostęp do swoich danych przez inne aplikacje. Dzięki temu mamy mnóstwo ciekawych programów, które bardzo często ułatwiają nam życie.

Pobraliśmy plik JSON na telefon — co dalej?

Wróćmy do tematu naszej aplikacji z przepisami. Pobraliśmy już nasz JSON, ale co teraz z tym zrobić? Przecież to zwykły tekst — jak zamienić to na żyjącą aplikację? Tu z pomocą przychodzi narzędzie nazywane Parserem. Zamienia ono ciąg znaków będący JSON-em na obiekt używanego przez nas języka programowania. Jeśli mamy już taki obiekt, możemy go używać w ten sam sposób jak inne obiekty, pochodzące przykładowo z bazy danych znajdującej się na urządzeniu mobilnym. Pobieramy odpowiednie pola z naszego obiektu i przypisujemy ich wartość do zdefiniowanych przez nas kontrolek widoku, na przykład pól tekstowych. Tłumacząc to na nieco prostsze słowa — do kontrolki odpowiedzialnej za wyświetlanie składników przypisujesz tekst znajdujący się pod polem „składniki” w naszym obiekcie.

To niestety już koniec na dzisiaj. Mam nadzieję, że udało mi się rozwiać Wasze wątpliwości. Jak zawsze zachęcam do komentowania oraz propozycji przyszłych tematów, jakie chcielibyście zobaczyć w ramach tego cyklu. Już za tydzień wracam z kolejnym odcinkiem, gdzie opowiem, jak działają pozwolenia w systemie Android. Widzimy się za tydzień!

Zapraszam również na największe w Polsce forum dla programistów Android. Jeśli macie pytania odnośnie kariery programisty — zapraszam do działu Kariera programowanie. Zachęcam również do przejrzenia działu Praca oraz zlecenia dla programistów — być może to właśnie tam znajdziesz swoją pierwszą pracę.

A może by tak… uczyć innych programowania?

Jako wykładowca poszerzasz swoją wiedzę i masz większą motywację do ciągłego rozwoju. Rozwijasz swoje umiejętności miękkie i ćwiczysz sztukę prezentacji. I co najważniejsze — masz wpływ na edukację młodego pokolenia programistów! A poza tym to po prostu dobra zabawa! Tutaj się dowiesz, w jakich technologiach możesz uczyć w Coders Lab.

Poprzednie odcinki: