Co to jest API REST?
REST API (czasami nazywany RESTful API) - aplikacyjny interfejs programistyczny architektury representational state transfer, często używany jako architektura przesyłania wiadomości i danych dla architektur klient-serwer i mikrousług.
Koncepcje REST API zostały opracowane dla sieci WWW i stanowiły podstawę jej rozwoju w chmurze, Edge, internecie mobilnym i internecie rzeczy (IoT).

Definicja interfejsu API REST
Interfejsy API są najpopularniejszym sposobem interakcji programów i urządzeń w nowoczesnych technologiach obliczeniowych. API to zestaw reguł opisujących, jak jeden program może się łączyć oraz komunikować z innym. Jak sama nazwa wskazuje, API REST przekazuje na każde żądanie stan każdej transakcji, co daje korzyści związane z opracowaniem, wydajnością i zasobami w porównaniu do innych metod. REST rozwija się w ciągu ponad dwóch dekad i jest bardzo powszechnym podejściem do architektur opartych na usługach i architektur rozproszonych.
Zasób jest podstawowym pojęciem dla API REST. Zasób jest obiektem, który ma typ, powiązane dane, relacje z innymi zasobami i zestaw metod, które na nim działają. Jest bardzo podobny do idei obiektów w programowaniu, chociaż zdefiniowanych jest tylko kilka standardowych metod, typowych dla HTTP GET, POST, PUT i DELETE. Zasoby mogą istnieć same lub w zbiorach, które same są zasobami.
W nowoczesnej informatyce wspólnym modelem - również podstawowym dla API REST - jest klient-serwer, gdzie klient, który potrzebuje zasobu, identyfikuje się i komunikuje z serwerem, który może go dostarczyć. W ten sposób zarządzany jest praktycznie cały ruch w chmurze, gdyż oferuje maksymalną elastyczność licznym klientom i pozwala na dostęp do licznych serwerów. Zasada ta sprawdza się również w przypadku tzw. architektur „bezserwerowych", w których miejsce serwera znanego klientowi zajmuje broker usług.
REST i sieć
Architektura API REST zaczęła ewoluować w 1993 roku, kiedy zaczęły pojawiać się strony WWW ogólnego użytku.
Gwałtowny rozwój internetu spowodował, że pojawiły się propozycje rozszerzeń konkurencyjnych do pierwotnego protokołu HTTP (HyperText Transfer Protocol). World Wide Web Consortium (W3C) i Internet Engineering Task Force (IETF) rozpoczęły prace nad oceną i sformalizowaniem nowych wersji standardów HTTP, HyperText Transfer Language (HTML) i URI.
Po sześciu latach pracy nad standaryzacją HTTP i URI, badacz Roy Fielding zdefiniował REST w 2000 roku, określając styl architektury pozwalający weryfikować przewidywany rozwój protokołów internetowych i zidentyfikować rozszerzenia, które nie sprawdzały się dla potrzeb związanych z zachowaniami i wydajnością sieci.
Następnie okazało się, że koncepcje REST można skutecznie dostosowywać do potrzeb informatycznych sieci. Od 2015 roku OpenAPI Initiative, sponsorowana przez Linux Foundation i wchodzące w jej skład firmy, takie jak Google, IBM, Microsoft i PayPal, stworzyła specyfikację OpenAPI opartą na regułach RESTful, która publikuje pliki interfejsu do odczytu maszynowego dla celów opisu, produkcji, konsumpcji i wizualizacji usług WWW RESTful.
Aplikacje implementowane na podstawie plików interfejsu OpenAPI mogą automatycznie generować dokumentację dotyczącą metod, parametrów i modeli. Poza tym że inicjatywa OpenAPI koncentruje uwagę branży na standardowych nagłówkach, kodach, opisach zasobów i przyszłych innowacjach, obejmuje również narzędzia, materiały referencyjne i najlepsze praktyki. Są one szczególnie ważne w procesie tworzenia, weryfikowania i właściwego używania uwierzytelniania i bezpieczeństwa danych w trybie RESTful, gdzie szczególną uwagę zwraca się na inicjatywę OpenAPI.
Sześć reguł projektowania API REST
Aby stać się API REST, API musi spełniać sześć reguł zwanych ograniczeniami architektonicznymi lub zasadami projektowania.
1. Jednolity interfejs
Wszystkie zapytania kierowane przez API REST muszą spełniać reguły formatowania określone przez API. Niezależnie od tego, jaki klient wysyła zapytanie, musi on przesłać każdą informację tam, gdzie zostawiłby ją każdy inny klient. Przykładem może być adres URL lub uniform Resource Locator, używany do identyfikacji zasobów za pośrednictwem protokołu HTTP - jest on przykładem identyfikatora URI (Uniform Resource Identifier), który może mieć większe zakresy.
2. Rozdzielenie klient-serwer
Interfejsy API REST wymagają, aby aplikacje klienckie i serwerowe były całkowicie niezależne od siebie. Klient powinien znać jedynie pełną nazwę zasobu, którego potrzebuje w przestrzeni wirtualnej dozwolonej przez API. W przeciwnym razie, jedyną wiedzą, jaką klient i serwer dysponują o sobie nawzajem są dane przesyłane przez transakcje API.
3. Bezstanowość
Każde żądanie klienta musi zawierać wszystkie informacje niezbędne do jego przetworzenia, a serwer nie musi przechowywać żadnych informacji o tym żądaniu po jego otrzymaniu. W projekcie API REST nie ma pojęcia sesji, a serwer jest bezstanowy w odniesieniu do konkretnego klienta.
4. Buforowalność
W przeciwieństwie do bezstanowości serwera w odniesieniu do klienta, zasoby powinny być dostępne w pamięci podręcznej w jednym lub kilku punktach wewnątrz lub między klientem a serwerem. Jeśli dany zasób został obsłużony i istnieje prawdopodobieństwo, że po pewnym czasie zostanie ponownie uruchomiony, należy uruchomić go w pamięci podręcznej w celu uzyskania szybszej odpowiedzi. Klient powinien podjąć podobną decyzję w sprawie otrzymanych zasobów. Serwer powinien poprzez API wskazać, czy zasób może być bezpiecznie umieszczony w pamięci podręcznej lokalnie u klienta, w tym, w stosownych przypadkach, czas życia danych. Projektowanie pamięci podręcznej, chociaż nie jest częścią specyfikacji API RESTful, jest krytyczne dla wydajności i projektanci API powinni wiedzieć, jak może to zostać zastosowane w praktyce.
5. Warstwowa architektura systemu
Konsekwencją rozdzielenia klient-serwer, bezstanowości i buforowalności jest to, że klient nie może przyjmować żadnych założeń co do tego, czy komunikuje się bezpośrednio z serwerem posiadającym określony zasób, czy też jest on obsługiwany przez pośrednika, takiego jak broker usług, load balancer, system dostarczania treści lub inny podsystem, znajdujący się bliżej klienta niż serwer. Zapewnia to projektantom systemów i infrastruktur dużą elastyczność, która pozwala maksymalizować wydajność i niezawodność odpowiedzi na zapytania w globalnej infrastrukturze przewodowej i bezprzewodowej. Leży to u podstaw funkcjonalności edge computingu.
6. Kod na żądanie
Chociaż API REST może udostępniać tylko dane do wykorzystania przez klienta i często tak robi, coraz częściej zdarza się, że do klienta dostarczany jest kod, na przykład obiekty Java lub aplikacje internetowe Javascript. W takim przypadku taki kod może być uruchomiony wyłącznie na żądanie klienta.
Działanie API REST
Interfejsy API REST mogą obsługiwać praktycznie każde żądanie dostępu, format danych, kontrolę zasobów lub komunikaty o stanie, ale reguła bezstanowości oznacza, że każde żądanie musi zawierać uwierzytelnienie niezbędne do jego zweryfikowania, dokładną definicję wymaganego zasobu i dokładne działanie, które jest wymagane.
Na przykład interfejs API systemu plików innego niż RESTful może odpowiadać na żądanie odczytu pliku zwracając dojście do pliku, mały token przypisany do sesji tak, aby klient mógł dokonywać wielokrotnych odczytów tylko przez odwołanie do tego dojścia. API REST musiałoby inaczej za każdym razem wysyłać klientowi nie tylko autoryzację, ale również pełny identyfikator zasobu wraz z dokładną lokalizacją w pliku danych do odczytania. Śledzenie całego procesu należy do decyzji klienta.
API REST przekazuje wszystkie te informacje za pośrednictwem kombinacji nagłówków i pól parametrów i może wymieniać rzeczywiste dane w dowolnym formacie. Bardzo popularnym standardem jest JSON, czyli format Javascript Object Notation, który mimo swojej nazwy jest czytelny zarówno dla ludzi, jak i dla maszyn, przez ludzkie oko lub przy użyciu któregokolwiek z popularnych języków programowania.
W projektowaniu API REST należy uwzględnić potrzebę zapewnienia efektywności, zwłaszcza w przypadku obsługi dużych transferów danych lub strumieni o krytycznym znaczeniu czasowym, lub odwrotnie, małych ilości danych ze źródeł o ograniczonych zasobach, takich jak systemy IoT.
OVHcloud i RESTful API
API OVHcloud to usługa WWW umożliwiająca klientom OVHcloud kupowanie, zarządzanie, aktualizowanie i konfigurowanie produktów OVHcloud bez korzystania z graficznego interfejsu klienta. Opiera się ona na najnowszym API RESTful i umożliwia zarządzanie prawie wszystkimi usługami OVH. Interfejs API został zaprojektowany tak, aby był prosty i łatwy w użyciu, a fragmenty kodu są dostarczane w wielu językach.
OVHcloud Manager (V6) jest teraz dostępny poprzez API OVHcloud. Każdy nowy produkt i każda nowa wersja produktu będą kompatybilne z API. W konsoli eksploratora API można przeglądać API, aby zapoznać się z wszystkimi dostępnymi funkcjami produktów OVHcloud, dostępnymi nawet dla osób niezarejestrowanych jako programiści. Możesz również wybrać produkt i przejrzeć dedykowane API, aby uzyskać informacje na temat powiązanych akcji.
API RESTful OVHcloud pozwala na szybki i lekki rozwój skryptów do niestandardowych funkcji, automatyzacji, tworzenia wielu zadań jednocześnie oraz narzędzi do wdrażania i zarządzania IaaS/PaaS. Obsługiwane języki to między innymi C, C++, C#, Java, Perl, PHP, Python, Ruby.