AWS API Gateway
Od jakiegoś czasu chcę przenieść jeden ze swoich projektów na rozwiązanie serverless. Ograniczanie kosztów, nowe zabawki. Sami wiecie.
Wnikam ostatnio głębiej w Amazon Web Services, pomyślałem więc o Lambdach. Szybko uruchomiłem sobie coś do testów. Miałem zamiar napisać trochę kodu, opisać implementację (AWS API Gateway, Lambda, może DynamoDB) w AWS i zapomnieć. Zacząłem jednak od dokumentacji AWS API Gateway i… powstanie chyba kilka wpisów.
AWS API Gateway
Za pomocą tej usługi możemy tworzyć RESTful api. Możliwości konfiguracji usługi są ogromne. W skrócie, zamiast pisać samemu kod, czy to w Node.js, czy innym NET.Core, możemy utworzyć sobie api za pomocą wygodnego interfejsu. Routing? Możemy zapomnieć. Ale możemy też użyć naszego API jako proxy i ogarnąć wszystko w naszej aplikacji lub lambdzie.
Startujemy
Na początek jednak coś łatwego, jakiś mock, który po prostu nam cos zwróci w response.
Po wejściu do API Gateway szukamy przycisku
lub jeżeli przypadkowo nie używamy języka francuskiego to
i otwieramy bogactwo możliwości. Jak już wspomniałem, na początku nie będziemy się jednak za bardzo rozpędzali.
Tworzymy więc nasze nowe API. Wpisujemy jakąś doniosłą nazwę i lecimy dalej
Ugólniajac, API to zbiór endpontów. Endpoint w rozumieniu AWS to połączenie zasobu (resource) i metody (method). Resource jest ścieżką (path) w naszym API, a nasza ścieżka może obsługiwać różne metody. GET, POST, PUT itd.
Pierwszym krokiem jest dodanie jakiegoś zasobu.
Wybierając akcję z menu trzeba pamiętać o wybraniu zasobu, na którym chcemy pracować. W naszym przypadku mamy tylko jeden, ale później dobrze jest sprawdzić, gdzie dodajemy kolejny zasób lub metodę.
Obowiązkowo wpisujemy nazwę naszego zasobu. Możemy także zmienić ścieżkę do tworzonego zasobu. Skupimy się jednak na dwóch opcjach, które nie są wymagane.
Proxy
W dużym skrócie, zaznaczenie tej opcji spowoduje, że te zasób stanie się czymś w rodzaju catch-all dla wszystkich innych zasobów i metod. Cały request jest przekazywany dalej, np. do funkcji lambda i sami możemy zająć się obróbką danych lub routingiem. My tego nie zaznaczymy.
CORS
Nie będę tłumaczył dokłądnie czym jest CORS. Zaznaczymy to jednak. Automatycznie utworzy to metodę OPTIONS dla naszego zasobu. Odpowiedź (response) dla tej metody będzie zawierała następujące nagłówki http
Dodajemy metodę
Kolejną metodą, którą dodamy, będzie GET. To już będziemy mogli sobie przetestować jakimś klientem. Zaznaczamy więc nasz zasób (resource1), klikamy w akcje
i wybieramy
W kolejnym kroku możemy wybrać sposób intergracji naszej metody z usługami. Mamy do wyboru:
- funkcje lambda,
- przekierowanie requestu do innego endpointa HTTP,
- zintegrowanie z inną usługą AWS,
- odesłanie przygotowanego przez nas mocka.
My wybierzemy sobie mocka, gdyż pozwoli nam to najszybciej uzyskać coś, co zadziała. Klikamy SAVE i w ten sposób utworzyliśmy naszego pierwszego endpointa.
Konfiguracja
Po utworzeniu metody ujrzymy coś, co może nas na początku trochę zdezorientować.
Górny wiersz pozwala na zdefiniowanie requesta, którego się spodziewamy w zapytaniu, a dolny na przygotowanie naszej odpowiedzi. Na tym etapie nie będziemy wnikali w szczegóły i możliwości, ustawimy sobie jednak to, co chcielibyśmy odesłać do klienta naszego API. Wchodzimy więc w 
i już możemy sobie co nieco pozmieniać. Udajemy się do Body Mapping Templetes i wybieramy application/json
Po prawej stronie powinniśmy zobaczyc coś na kształt osadzonego edytora, w którego wpiszemy sobie jakiś objekt JSON. Może nie jakiś, bo obowiązują nas zasady dobrego wychowania, proponuję więc na początek wpisac tam:
{"message" : "Hurra! Dzięki chmurowisko.pl Mój API Gateway działa."}
Powinniśmy mieć coś takiego
Zapisujemy i zanim rzeczywiście zadziała, musimy nasze API uruchomić. Czyli robimy deployment, Actions -> Deploy API
Pojawia nam się kolejna fajna możliwość AWS, stages. Tak, możemy mieć wiele wersji naszego API. Super sprawa. Wersja produkcyjna, deweloperska, pierwsza, druga, trzecia, zapomniana.
Klikamy w deploy i pojawia nam się kolejna strona z mnóstwem możliwości. To co nas w tym momencie interesuje to adres url, pod którym możemy nasze API poprosić o odpowiedź.
Otwieramy szybko adres w przeglądarce i czeka nas rozczarowanie. Dostaliśmy JSONa, ale nie jest to zdecydowanie obiekt, który zdefiniowaliśmy. Otrzymaliśmy informację o błędzie {"message":"Missing Authentication Token"} A miało działać… Przyjrzyjmy się adresowi. Wywołujemy nasze API, ale nie naszą metodę. Routingiem zajmuje się nasz API Gateway, więc musimy dodać ścieżkę do naszej metody. Dopisujemy więc naszą ścieżkę resource1 i wywołujemy https://sq7eshag0k.execute-api.eu-central-1.amazonaws.com/dev/resource1. W Waszym przypadku url będzie na pewno wyglądał inaczej, ale efekt powinien byc taki sam lub podobny.
Poznaliśmy wierzchołek góry. Lodowej? Niekoniecznie. W przypadku AWS API Gateway mozliwości przesłaniają zdecydowanie zagrożenia.