Spis treści:
  1.  Wprowadzenie. Dlaczego warto poznać REST i co to jest?
  2.  Dlaczego warto tworzyć API?
  3.  Jak działa REST?
  4.  Wady i zalety

 

Wprowadzenie. Dlaczego warto poznać REST i co to jest?

 

REST (Representational state transfer) – Jest to sposób budowy systemu według okerślonych zasad – wzorzec architektury. Dzięki tym zasadom możemy w prosty i szybki sposób zbudować bardzo sprawne API (Application Programming Interface), które wykorzystamy w naszym produkcje/aplikacji/systemie.
Jest to obecnie najpopularniejszy wzorzec architektury serwisów
z którego korzysta około 69% serwisów [1]. Między nimi możemy znaleźć serwisy takie jak: Netflix, Facebook, Instagram, Youtube, Slack i tysiące innych. Nie oznacza to że REST API przeznaczone jest tylko do dużych serwisów, w bardzo prosty sposób mozesz go zaimplementować nawet w prostych projektach.
Odpowiedzmy sobie najpierw na pytanie dlaczego tworzymy nasz serwis oraz kto korzysta z naszych usług?

Z naszego serwisu będą korzystać użytkownicy, współpracownicy, programiści albo też inne serwisy. Żeby umożliwić użytkownikom i serwisom korzystanie z naszych usług tworzymy pewien interfejs (API) przez który otrzymają od nas jakąś usługę (np. Wrzucenie filmu na YouTuba, wyświetlenie profilu na Instagramie, dostęp do nowego odcinka „Gry o tron”).

 

Architekturę typu REST używa się w serwisach które mają być „otwarte na świat”.  Możemy w prosty sposób udostępniać zasoby dla wielu klientów.  I tu muszę się zatrzymać. Mówiąc „otwarte na świat” nie mam na myśli „dostępne dla każdego”. Często jest tak ze to co widzi użytkownik jest tylko wierzchołkiem góry lodowej, wiele zapytań REST odbywa się między samymi serwisami i użytkownik nie wie że jego zapytanie wywołało serie wielu innych zapytań.
REST API jest powodem wzrostu popularności serwisów społecznościowych. Dzięki temu jedne serwisy/usługi mogą korzystać z drugiego serwisu bez większych problemów.  Mogę udostępnić ten artykuł na FB czy Twitterze za pomocą wtyczki która wstawi post na moja tablice w serwisie społecznościowym. Kolejnym przykładem jest serwis  accuweather.com  wiele innych aplikacji korzysta z danych które udostępnia ten serwis. Użytkownicy mogą nawet nie wiedzieć że korzystają z innych serwisów. Dla programistów natomiast architektura REST API oznacza szybką i łatwą integracje usług.

Dlaczego warto tworzyć API?

Przepraszam że czasem łącze pojęcia REST i API ale w kontekście serwisu te pojęcia ciągle z sobą współgrają. API to tylko interfejs natomiast REST to model architektury. Razem tworzą pewną funkcjonalność o którą nam chodzi.

Projektowanie i tworzenie API to wieloetapowy proces. Dobrze zaprojektowany interfejs wymaga wiele wysiłku i doświadczenia jednak wszystko to zwróci się podczas dalszej pracy nad serwisem. API tworzymy aby udostępnić użytkownikom lub innym serwisom pewne usługi które nasz serwis oferuje.

Co składa się na nasz interfejs (API)?

 

Specyfikacja według której komunikujemy się z serwisem (na przykładzie REST API).

 

Jako uzytkownik możemy poprosić o dostęp do zasobów. Mozemy je również edytować, dodawać i usuwać. (więcej o modelu CRUD będzie później)
np. GET nasz_serwis/api/users/adam wówczas pobierzemy dane użytkownika Adam, natomiast POST nasz_serwis/api/users/ doda nam uzytkownika
Dobrze, ale czy jako zwykły użytkownik moge edytować dane innego użytkownika? Tutaj wchodzą w gre pewne ograniczenia związane z serwisem. REST nie zapamiętuje stanu więc komunikacja i dostęp do zasobów odbywa się na zasadzie tokenów przyznawanych użytkownikom. Token to taki klucz dostępu który upoważnia Cię (lub grupę) dając pewne prawa do użytkowania zasobami. Warto wiedzieć że popularnym systemem (protokołem) autoryzacji jest Oauth lub nowsza wersja OAuth2.0.  Korzystają z tego serwisy takie jak Google czy Facebook.
Ograniczenie dostępu jest ważnym elementem naszego serwisu, pozwala na dodanie wpisu na tablicy ale tylko właścicielowi (albo również znajomym).  Być moze logowałeś się do jakiejś usługi za pomocą konta Google czy Facebook, wówczas musisz potwierdzić czy zezwalasz danej aplikacji na dostęp do jakiegoś zasobu np. dane osobowe, lista znajomych,  kontakty. Aplikacja wówczas uzyskuje token i za jego pomocą „w Twoim imieniu” może dokonywać zmian w tych chronionych zasobach.
Mamy możliwość obserwowania wykorzystania zasobów oraz ruchu w naszym serwisie. Np. Ile osób widziało dany produkt, a ile z nich go kupiło. Byli to użytkownicy smartphonów? W jakich godzinach przeglądali daną ofertę? Możliwość obserwacji zasobów jest bardzo ważna dla właścicieli serwisu. Netflix może badać popularność swoich programów albo określić kiedy i z jakich urządzeń był wzmożony ruch.
Niektóre serwisy wprowadzają ograniczenia techniczne które chronią serwisy przed przeciążeniem. Mogą to być limity zapytań czyli ile razy dany użytkownik lub aplikacja mogą użyć serwisu w ciągu godziny, miesiąca itd. Czasem określa się  koszt  danego zapytania i wyświetlenie będzie mniej kosztowne niż edycja. Dzięki ograniczeniom nasze API może być mniej przeciążone i podatne na ataki. Serwisy udostępniające API często wymagają wygenerowania klucza dostępu. Pozwala to serwisowi na przypisanie aplikacji/użytkownika do wykonywanych przez niego zapytań i naliczaniu kosztu.
Warto wspomnieć że na dobre API składa się dobra dokumentacja dzięki której jako twórcy, programiści, współpracownicy będziemy mogli łatwo zrozumieć dany system. Poniżej podam parę przykładów:

Wrócę jeszcze do projektowania interfejsu, dlaczego to jest takie ważne? Tutaj powinniśmy położyć największy nacisk gdyż jest to kluczowy element naszego serwisu. Powinniśmy zaplanować nasze cele biznesowe i dostarczyć takie API by spełniało nasze wymagania. Zmiana interfejsu po etapie projektowania jest czymś czego nie chcemy. Inne serwisy korzystające z API mogą odwoływać się do zasobu który nie istnieje. Ważne żebyś położył nacisk na przemyślaną architekturę swojego interfejsu, gdyż późniejsza jego zmiana może mieć wiele konsekwencji. Implementacje zaś możesz zmieniać dowolnie.

 

* Często powoływałem się w przykładach na Facebooka, prawda jest jednak taka że FB korzysta z GraphQL API a nie REST API. Jest to nowy standard i alternatywa dla modelu REST.  GraphQL pozwala na zagnieżdżone i bardziej elastyczne zapytania (możemy wysyłać zapytania o konkretne pola).

 

Ciekawy artykuł na temat GraphQL możecie przeczytać tutaj: http://devenv.pl/graphql-podstawy/ 
Podam parę ciekawostek [2]:
  • Ponad 30% internetowego ruchu sieciowego w najlepszym czasie antenowym w Stanach Zjednoczonych powiązane jest ze strumieniowaniem w serwisie Netflix, które jest zapewniane i zarządzane poprzez interfejsy API.
  • W 2015 roku firma Facebook odpowiadała za ponad 25% całkowitej liczby wyświetleń stron internetowych. Interfejsy API obsługują zarówno produkty tej firmy, jak i jej „ekosystem”.
  • Firma Salesforce.com stworzyła duży i rozbudowany „ekosystem” partnerów, udostępniając im podstawowe usługi w celu rozszerzania ich i wprowadzania do nich innowacji. Obecnie interfejs API serwisu Salesforce obsługuje większy ruch sieciowy niż witryna internetowa tej firmy. W połowie roku 2011 ponad 60% ruchu sieciowego kierowanego do tego serwisu trafiało do niego za pośrednictwem interfejsów API.
Jak widzisz stworzenie odpowiedniego interfejsu może sprawić że Wasza usługa nie tylko będzie łatwiejsza w użyciu przez Was samych, ale również będą z niej mogli skorzystać inne osoby lub serwisy. Dzięki temu serwisy takie jak twitter czy accuweather zyskały na tak dużej popularności.

 

 

 Jak działa REST?

 

REST opiera się na zapytaniach poprzez adresy URL wysyłanymi przez protokół HTTP. Pokaże to na przykładzie:
Mamy adres url (z serwisu Youtube) :
Podzielmy go na składowe:
  • https/http – protokół
  • www.youtube.com – host
  • channel – pewien zasób (zbiór)
  • UC29ju8bIPH5as8OGnQzwJyA – ID konkretnego kanału
Teraz spróbuj wkleić ten adres do przeglądarki:
(Polecam zainstalować wtyczke do wyświetlania plików JSON w przeglądarce np. JSON Viewer)
Mozesz sam rozkodować o co chodzi w podanym adresie dzięki dokumentacji YouTube na stronie :
Tak jak poprzednio mamy protokół i hosta ale nasze zapytanie wygląda zupełnie inaczej. Naszym hostem jest „googleapis” czyli serwis przez który Google udostępnia swoje API.
Następnie odwołujemy się do „/youtube/v3” jest to API serwisu YouTube w wersji 3.
Dalej mamy „/channel” jest to zasób w którym dokonujemy zapytania. Znak „?” oznacza nam zapytanie wszystko co po nim to argumenty naszego zapytania które mają postać „argument=wartosc” które połączone są spójnikiem „&”.
Tłumacząc nasz przykład: „part=snippet%2CcontentDetails%2Cstatistics” (%2C oznacza przecinek – możesz je stosować zamiennie) tutaj odwołujemy się konkretnie do danych do których chcemy uzyskać dostęp.
Jeśli w naszej aplikacji są nam potrzebne tylko statystyki, wówczas bierzemy tylko „part=statistics”. Dalej jest pole „id” czyli do jakiego konkretnie kanału odnosimy nasze zapytanie. Na końcu mamy „key” jest to mój unikalny numer klienta który utworzyłem by móc wykonywać zapytania. Google przyznało mi limity do wykorzystania i dzięki kluczowi może mnie zidentyfikować.
Mozesz utworzyć swój własny klucz poprzez platformę https://console.developers.google.com. Jeżeli chcesz zobacz API które udostępniają swój interfejs na stronie https://any-api.com/ . Zajrzyj do dokumentacji by sprawdzić mozliwości jakie udostępnia konkretne API, uzyskaj klucz dostępu i korzystaj! Możesz wykorzystać zewnętrzne narzędzia jak Postman. cURL lub dodatek do chrome REST client by tworzyć zapytania URL.

 

Jest jeszcze jedna rzecz o której chciałbym wspomnieć. Jest to kolejny skrót. CRUD czyli create\read\update\delete jest to koncepcja według której tworzone jest REST API. Udostępniamy użytkownikom tworzenie, odczytywanie, edycje i usuwanie zasobów. Do tego wykorzystujemy metody HTTP: POST, GET, PUT, DELETE więcej możecie poczytaj pod linkiem:
Dodatkowo każde nasze zapytanie wiąże sie z kodem odpowiedzi (zobacz: http://www.restapitutorial.com/lessons/restquicktips.html lub https://pl.wikipedia.org/wiki/Kod_odpowiedzi_HTTP )

Wady i zalety REST API

 

Zalety:

  • Niezależność od technologi i platform.
    Jeśli chcemy napisać aplikacje na androida a nasz REST serwer jest napisany w Node.js to nie jest problem. Korzystająć z API możesz wykorzystać funkcjonalności Twojego serwisu w Twojej aplikacji mobilnej napisanej w Javie.
  • Bezstanowy
    Możesz obsługiwać wielu klientów na raz dużo sprawniej niż przy wykorzystaniu innej architektury, serwer nie zapamiętuje stanu klienta. Dzięki temu serwis działa szybciej.
  • Łatwy dostęp
    Jeżeli informacje mają być udostępnione dużej ilości ludzi REST sprawdzi się idealnie. Przykładem są róznego rodzaju serwisy społecznościowe (facebook, twitter, youtube itd.)

    • Wsparcie dla formatu JSON (bez problemu możesz konwertować obiekty w format JSON który jest wspierany przez JS)
    • Możliwość tworzenie API w przystępny sposób. Możliwość tworzenia dokumentacji wraz z pisaniem kodu. (Np. Dodatek do Hapi.js)

Wady REST

  • Serwer nie zapamiętuje stanu klienta
    Jest to zaleta ale i wada. Komunikacja z serwerem i dostęp do niektórych funkcjonalności wymaga stosowanie tokenów które służą do autoryzacji żądania. Część funkcjolnalności (np. edycja profilu użytkownika, dodanie komentarza, dostęp do wraźliwych danych) nie są dostępne z głównego poziomu naszej aplikacji, wymagają pewnej autoryzacji. Jako że REST nie zapamiętuje stanu, nie wie czy uzytkownik jest zalogowany z tego to powodu autoryzacja odbywa się za pomocą tokenów. Serwisów takich nie używa się w miejscach gdzie potrzebne jest duże bezpieczeństwo. Na przykład systemy bankowe korzystają z architektury SOAP która jest bezpieczniejszym rozwiązaniem.Dodatkowo to klient jest zmuszony do zarządzania stanem aplikacji na podstawie otrzymanych odpowiedzi.
  • Komunikacja Klient-Serwer opiera się na pojedynczym żądaniu
    Dlatego kod aplikacji może się rozrosnąć w przypadku gdy chcemy wykonać parę zagnieżdżonych żądań. Np. Wyświetlić wiele komentarzy które są stronicowane.

[1] – [żródło: https://www.programmableweb.com/apis, ikonografika: https://visual.ly/community/infographic/computers/api]
[2] – [żródło: Książka, Interfejs API. Strategia programisty, autorzy: Daniel Jacobson, Greg Brail, Dan Woods]

 

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *