Zrozumienie platform opartych na API: przewodnik dla menedżerów produktów

Zbudowanie produktu cyfrowego dzisiaj oznacza integrację niezliczonych różnych systemów back-office z punktami kontaktu i urządzeniami z klientami. Koszt zaangażowania zespołu programistów w celu połączenia ich w jedno działające rozwiązanie może wzrosnąć w górę.

Dlatego współcześni menedżerowie produktów, wybierając dostawców, często na pierwszym miejscu stawiają możliwości integracyjne, co może sprowadzać się do wyboru systemów eksponujących API. Czym jest API i jak go przetestować bez angażowania zespołu technicznego? Czytaj.

Uwzględnij dane: dlaczego w ogóle potrzebujemy interfejsów API

Dane klientów zmieniają sposób działania firmy. Odpowiednio zebrane i przesunięte, mogą pomóc firmom zwiększyć wskaźniki pozyskiwania i retencji klientów, prowadząc ostatecznie do wzrostu dochodów.

Ale przetwarzanie danych to żmudna praca. Dlatego biznes sięgnął po informatykę. W latach 90. bazy danych, które automatyzowały najbardziej czasochłonne zadania związane z danymi, zyskały ogromną popularność w działach marketingu. Doprowadziło to do ogromnej zmiany w sposobie pojmowania strategii marketingowych — zmiana ta została nazwana podejściem opartym na danych .

Bazy danych miały jednak poważny problem. Aby uczynić z nich coś wartościowego, firma musiała zatrudnić inżynierów oprogramowania. Byli bohaterami, którzy wiedzieli, jak zamienić ogromne stosy danych w robocze spostrzeżenia. Byli również strażnikami chroniącymi integralność danych, a tym samym zapewniającymi, że system będzie gotowy na przyszłość.

Ale inżynierowie oprogramowania kosztują dużo, a ich interfejs komunikacyjny wymaga wysiłku.

Gdy liczba kanałów zbierania danych obejmowała kilka działów, a nawet firm zewnętrznych, bazy danych i ich operatorzy stawali się wąskim gardłem. Firmy musiały znaleźć zautomatyzowany sposób uzyskiwania dostępu do magazynów danych.

Tak powstała idea systemów API-first.

Czym właściwie jest API bez Tech Lingo

Systemy API-first, dziś powszechnie nazywane API ( interfejs programowania aplikacji), to aplikacje, które zapewniają innym systemom dostęp do swoich danych w ujednolicony i bezpieczny sposób.

Bez oceny z informatyki interfejs programowalny aplikacji naprawdę nie dzwoni. Przyjrzyjmy się bardziej namacalnemu wyjaśnieniu.

Jedna z najlepszych analogii, jakie do tej pory znalazłem w sieci, została napisana przez Taiję:

„Jeśli idziesz do restauracji jako klient, nie możesz wejść do kuchni. Musisz wiedzieć, co jest dostępne. Do tego masz menu. Po obejrzeniu menu składasz zamówienie do kelnera, który przekazuje je do kuchni, a następnie dostarcza to, o co prosiłeś. Kelner może dostarczyć tylko to, co może zapewnić kuchnia.

Najlepsza analogia API, jaką widziałem: weź restaurację. Menu to API, twoje zamówienie to wywołanie API, jedzenie z kuchni to odpowiedź.

— Aarthi 發財 ! (@AarthiD) 19 grudnia 2013

Jak to się ma do API? Kelner to API. Jesteś kimś, kto prosi o usługi. Innymi słowy, jesteś klientem lub konsumentem API. Menu to dokumentacja wyjaśniająca, o co można poprosić w interfejsie API. Kuchnia to na przykład serwer; baza danych, która zawiera tylko pewien rodzaj danych — cokolwiek kupujący kupił dla restauracji jako składniki i co szef kuchni zdecydował, że zaoferuje, i co kucharze wiedzą, jak przygotować”.

Więc znowu:

• Kuchnia
  Baza danych bez klientów pozwoliła na ochronę integralności danych.
• Kelner
  API, pośrednik, który wie, jak obsłużyć dane z bazy danych bez zakłócania jej funkcjonowania.
• Klient
  Zewnętrzny system, który chce uzyskać ich dane
• Menu
  Format danych odnosi się do systemów zewnętrznych, z których muszą korzystać, aby wykonać swoje działanie.
• Zamówienie
  Rzeczywiste pojedyncze wywołanie API.

Przy obecnym stanie technologii wciąż potrzeba programisty, aby „złożyć zamówienie”. Ale jest o wiele szybciej (czytaj: taniej), bo menu, podobnie jak McDonald's, jest mniej więcej ujednolicone na całym świecie.

A więc teraz założymy buty programisty i spróbujemy wywołać przykładowe API. Nie martw się; nie wyjdziemy poza szkolne zajęcia z informatyki.

Jak Twoja aplikacja pogodowa pobiera dane: podstawy interfejsu API

Dowiemy się, w jaki sposób Twoja aplikacja pogodowa zna aktualną temperaturę. W ten sposób poznamy podstawy komunikacji z systemami przez Internet.

Czego potrzebujemy:

• Baza danych o pogodzie
• Przeglądarka
• Odrobina siły woli

Otóż ​​to! Dzisiejsza technologia ułatwia testowanie interfejsu API bez konieczności używania dużych narzędzi programistycznych.

Oczywiście inaczej jest, gdy chcesz stworzyć pełną integrację. Kiedy pojawia się push, musisz znać bardziej zaawansowane narzędzia i języki programowania, ale do testowania/weryfikacji koncepcji wystarczy ta konfiguracja.

Spróbujmy więc uzyskać aktualny wskaźnik temperatury dla Twojego miasta — lub, mówiąc w żargonie programistów — wywołajmy pierwsze wywołanie API. W końcu sprowadza się to do wysłania jakiegoś tekstu na serwer i otrzymania w zamian wiadomości .

Anatomia żądania API

W tym artykule będziemy używać https://openweathermap.org API. Odwiedź stronę i spróbuj sprawdzić warunki pogodowe w kilku miejscach. Mam nadzieję, że dziś w Katowicach czujesz się lepiej niż ja:

Jak można się domyślić, witryna wywołuje API, aby uzyskać dane. Deweloperzy zaimplementowali go w taki sposób, że za każdym razem, gdy naciśniesz search , aplikacja puka do drzwi API i mówi „daj mi <miasto> temperaturę”.

Załóżmy czapkę hakera i zobaczmy, jak wywołania API ta strona internetowa wywołuje w Twojej przeglądarce. Możesz użyć Narzędzi dla programistów w swojej przeglądarce, aby zobaczyć, co dzieje się za kulisami:

1. W Chrome przejdź do Menu → Więcej narzędzi → Narzędzia programistyczne;
2. Przejdź do zakładki Sieć;
3. Spróbuj sprawdzić temperaturę w różnych miastach w powyższym widżecie;
4. Na liście na dole zauważysz linki, które zostały nazwane:
   

   

   
   Jeśli skopiujesz link, zobaczysz, że zawiera nazwę lokalizacji i kilka innych parametrów.
   

    https://openweathermap.org/data/2.5/find?callback=jQuery19103887954878001505_1542285819413&q=Katowice&type=like&sort=population&cnt=30&appid=b6907d289e10d714a6e88b30761fae22&_=1542285819418

5. Gdy wkleisz link do paska adresu przeglądarki, powinieneś zobaczyć odpowiedzi API z:
   

    jQuery19103887954878001505_1542285819413({"message":"accurate","cod":"200","count":1,"list":[{"id":3096472,"name":"Katowice","coord":{"lat":50.2599,"lon":19.0216},"main":{"temp":281.69,"pressure":1031,"humidity":61,"temp_min":281.15,"temp_max":282.15},"dt":1542285000,"wind":{"speed":3.6,"deg":50},"sys":{"country":"PL"},"rain":null,"snow":null,"clouds":{"all":90},"weather":[{"id":804,"main":"Clouds","description":"overcast clouds","icon":"04d"}]}]})

6. Jest to trochę chaotyczne, ale jeśli wyjmiesz zawartość nawiasów i uruchomisz go za pomocą programu do formatowania danych, zobaczysz strukturę, która ma sens:
   

    { "message":"accurate", "cod":"200", "count":1, "list":[ { "id":3096472, "name":"Katowice", "coord":{ "lat":50.2599, "lon":19.0216 }, "main":{ "temp":281.69, "pressure":1031, "humidity":61, "temp_min":281.15, "temp_max":282.15 }, "dt":1542285000, "wind":{ "speed":3.6, "deg":50 }, "sys":{ "country":"PL" }, "rain":null, "snow":null, "clouds":{ "all":90 },

7. Odpowiedź z API to struktura danych z informacją o aktualnych warunkach pogodowych — większość parametrów należy bez problemu odszyfrować. Ten format danych nazywa się JSON . Jest to ważna notacja, ponieważ korzysta z niej większość nowoczesnych interfejsów API. Ten stos identyfikatorów i nawiasów służy jednemu celowi — aplikacji jest łatwiej przeanalizować dobrze zorganizowaną wiadomość niż losowo umieszczony tekst.

Słowo wyjaśnienia tego, co właśnie tutaj zrobiliśmy.

Aplikacja internetowa stojąca za stroną Open Weather Map pobiera dane z API i wyświetla je na stronie.

Za każdym razem, gdy wpiszesz nazwę miasta i naciśniesz przycisk wyszukiwania , witryna łączy się z serwerem z określonym linkiem, który zawiera jako parametr nazwę miasta.

To samo zdanie w technicznym żargonie: aplikacja za stroną wysyła żądanie do punktu końcowego API , podając jako argument nazwę miasta .

Następnie API odpowiada (wysyła odpowiedź API ) wiadomością tekstową sformatowaną jako JSON .

Aby utworzyć żądanie API, musisz połączyć jego adres. Tak, adres to dobra analogia. Aby wysłać coś musisz dostarczyć kurierowi:

• Miasto,
• Ulica i numer,
• Czasami dodatkowe informacje o tym, jak dostać się do biura.

Aby połączyć się z API, analogicznie, potrzebujesz:

• https://openweathermap.org/ (link) Miasto lub główny punkt końcowy — w naszym przypadku punkt początkowy, adres internetowy serwera, z którym chcesz się połączyć.
• data/2.5/find (link) Numer ulicy lub ścieżka — określa zasób, który chcesz uzyskać z API.
• ?callback=jQuery19103887954878001505 1542285819413&q=Katowice&type=like&sort=population&cnt=30&appid=b6907d289e10d714a6e88b30761fae22& =1542285819418 (link) Dodatkowe informacje lub parametry zapytania — poinformuj serwer API w jakiej konkretnej strukturze zamówienia i jakiej struktury chcemy.

W ten sposób projektuje się interfejsy API. Główny punkt końcowy zwykle pozostaje taki sam dla jednego dostawcy, wtedy musisz dowiedzieć się, jakie parametry ścieżki i zapytania są dostępne i jakie informacje umieścił za nimi zespół programistów API.

Teraz załóżmy nieco mocniej czapkę hakera. W naszym przypadku nie wszystkie parametry zapytania są niezbędne do uzyskania danych pogodowych. Spróbuj usunąć różne parametry po znaku zapytania ( ? ) i sprawdź, jak odpowiada Weather API.

Na przykład możesz zacząć od usunięcia callback z łącza żądania:

 https://openweathermap.org/data/2.5/find?callback=jQuery19103887954878001505_1542285819413&q=Katowice&type=like&sort=population&cnt=30&appid=b6907d289e10d714a6e88b30761fae22&_=1542285819418

Wynik:

 https://openweathermap.org/data/2.5/find?q=Katowice&type=like&sort=population&cnt=30&appid=b6907d289e10d714a6e88b30761fae22&_=1542285819418

Jeśli pobawisz się innymi, możesz zobaczyć, że niektóre z nich są również opcjonalne. Właściwie tylko q i appid są obowiązkowe:

 https://openweathermap.org/data/2.5/find?q=Katowice&appid=b6907d289e10d714a6e88b30761fae22

Skąd wiesz, co jest obowiązkowe, a co opcjonalne? Skąd wiesz, gdzie w pierwszej kolejności uzyskać główny punkt końcowy i ścieżkę?

Dokumentacja API: musisz przeczytać przed rozpoczęciem

Zawsze musisz najpierw sprawdzić dokumentację API, aby dowiedzieć się, jak prawidłowo skonstruować żądanie.

W naszym przypadku dokumentacja https://openweathermap.org/current pokazuje dostępne punkty końcowe. Wyjaśnia również wszystkie pola danych odpowiedzi — dzięki czemu możesz znaleźć informacje, na które odpowie interfejs API, nawet zanim wyślesz żądanie.

Dobra dokumentacja API oferuje samouczki szybkiego startu, jak tworzyć proste żądania i przechodzić do bardziej zaawansowanych rzeczy. Na szczęście Open Weather API ma jeden i zamierzamy go teraz używać.

Tworzenie wywołania API od podstaw

Podsumujmy nasze ustalenia. Wysłaliśmy już żądanie do interfejsu API. Znaleźliśmy poprawny link, węsząc za kulisami, co OpenWeatherMap robi. Takie podejście nazywa się inżynierią odwrotną i często jest trudne lub w ogóle niemożliwe.

Co więcej, w większości przypadków dostawcy API zabraniają użytkownikom nadużywania tej opcji. Dlatego powinniśmy nauczyć się „wywoływać” API zgodnie z regułami (czyli dokumentacją).

Jednym ze sposobów na to jest zakodowanie tego. Ale ponieważ nie jesteśmy programistami ( jeszcze! ​​), zamierzamy użyć narzędzi, które to ułatwią. O wiele łatwiejsze, że nawet programiści mają go pod swoim paskiem narzędzi.

Zgodnie z obietnicą nie opuścimy przeglądarki. Ale musimy zainstalować rozszerzenie (tylko Chrome) — Listonosz. Ta prosta wtyczka zamienia Twoją przeglądarkę w złącze API.

OK, teraz, gdy mamy narzędzie, zajrzyjmy do dokumentacji, aby zobaczyć, jak możemy uzyskać aktualne warunki pogodowe dla określonej nazwy miasta https://openweathermap.org/current#name .

Dokumenty mówią, że powinniśmy użyć następującego punktu końcowego: api.openweathermap.org/data/2.5/weather?q={city name}

Kiedy to rozbijemy, otrzymamy następujące elementy:

• Główny punkt końcowy: api.openweathermap.org
• Ścieżka: data/2.5/weather
• Parametr zapytania: q={city name} (to pojęcie oznacza, że ​​powinniśmy zastąpić nawiasy klamrowe konkretną nazwą miasta)

Włóżmy to do Postmana. Proces sprowadza się do trzech prostych kroków:

1. Kliknij „Zapytanie” w górnym menu.
   

   

2. Nazwij swoją prośbę i podaj nazwę katalogu w sekcji na dole.

   

3. Wklej punkt końcowy API, który chcesz wywołać, kliknij Wyślij i powinieneś zobaczyć odpowiedź API w sekcji Odpowiedź:

   

Gratulacje! Właśnie pomyślnie wezwałeś swoją jodłę… poczekaj chwilę! Zwróćmy uwagę na odpowiedź API:

Nie jest to plik JSON wypełniony informacjami o pogodzie, które widzieliśmy wcześniej. Co w ogóle oznaczają 401 i nieprawidłowy klucz API? Czy nasza dokumentacja jest błędna?

Uwierzytelnianie

Nie pozwolisz nikomu wejść do swojego barku bez Twojej zgody, prawda? Z tego samego powodu dostawcy API chcą również kontrolować użytkowników swojego produktu, aby chronić go przed złośliwą aktywnością. Co to jest złośliwa aktywność? Na przykład wysyłanie wielu żądań API jednocześnie, co spowoduje „przegrzanie” serwera i spowoduje przestój dla innych użytkowników.

Jak możesz kontrolować dostęp? Tak samo jak pilnujesz swoich napojów! Za pomocą kluczy — klucze API .

Jeśli odwiedzisz przewodnik Jak zacząć z dokumentacji interfejsu Weather API, zauważysz, w jaki sposób możesz uzyskać swój klucz. Zarejestruj się teraz i sprawdź swoją skrzynkę odbiorczą.

Więc teraz pytanie brzmi, jak używać klucza? Zgodnie z dokumentacją jest to łatwe, wystarczy skopiować i wkleić klucz na końcu adresu URL punktu końcowego (bez nawiasów klamrowych).

 api.openweathermap.org/data/2.5/weather?q=Katowice&appid={your API key}

I ponownie kliknij wyślij. Proszę bardzo, teraz możemy zobaczyć odpowiedź API!

Ale z API Postmana można uzyskać znacznie więcej. Gotowy, aby zostać prawdziwym hakerem API?

Parametry API: uzyskiwanie dopasowanych odpowiedzi

Zazwyczaj punkty końcowe API mają pewne funkcje użytkowe, których można użyć do dostosowania odpowiedzi API, np. jeśli potrzebujesz lepszego formatu danych lub chcesz uzyskać dane w określonej kolejności. Opcje te są często ukryte za niektórymi parametrami, które można znaleźć w dokumentacji.

Parametry zapytania to po prostu tekst strukturalny, który dodajesz pod adresem punktu końcowego z następującym wzorcem:

1. Znak zapytania ( ? ) po ścieżce,
2. nazwa parametru,
3. Równa się ( = ) symbol,
4. Wartość parametru,
5. Ampersand ( & ) i inne następują z punktami 2-4 (w ten sposób możesz dodać tyle parametrów, ile chcesz).

Weźmy jako przykład naszą pierwszą prośbę:

 https://openweathermap.org/data/2.5/find?q=Katowice&appid=b6907d289e10d714a6e88b30761fae22

Ważna uwaga: kolejność parametrów zapytania nie ma znaczenia.

 ?q=Katowice&appid=b6907d289e10d714a6e88b30761fae22

Powyższe jest takie samo jak poniżej:

 ?appid=b6907d289e10d714a6e88b30761fae22&q=Katowice

Jak wspomniano, parametry zapytania są opisane w dokumentacji API. Poniższy fragment dokumentacji API pogody pokazuje, jak uzyskać temperaturę w różnych jednostkach (imperialnych lub metrycznych):

Spróbuj wysłać te dwie opcje za pomocą Postmana, aby zobaczyć różnicę w wynikach. Pamiętaj, aby dodać klucz API na końcu adresu punktu końcowego.

Uwaga : Zawsze poświęć trochę czasu na przestudiowanie dokumentacji i znalezienie parametrów, które mogą zaoszczędzić Tobie lub Twojemu zespołowi programistycznemu sporo czasu.

Opcje żądań API: jak wysłać dane do API

Do tej pory otrzymywaliśmy informacje z API. Co jeśli chcemy dodać lub zmodyfikować informacje w bazie danych za API? Odpowiedzią są metody żądania.

Przyjrzyjmy się jeszcze raz Postmanowi. Być może zauważyłeś etykietę GET pisaną wielkimi literami obok adresu punktu końcowego interfejsu API. Jest to jedna z czterech metod żądania. GET oznacza, że ​​chcemy uzyskać coś z API (dzięki kapitanie) i jest to opcja domyślna. Jakie są inne opcje?

Wciąż zagmatwane? Przejdźmy do przykładów.

POST API: Jak utworzyć rekord w API

Nie możemy tworzyć ani aktualizować niczego za pomocą Weather API (ponieważ ma być tylko do odczytu), więc musimy znaleźć inny do celów testowych.

Podajmy przykład bardziej zorientowany na biznes. Przeprowadzimy symulację następującego scenariusza:

Jeśli pada deszcz, stwórz kupon rabatowy „rozweselający” dla swoich klientów.

Zamierzamy użyć Voucherify, który zapewnia API do tworzenia i śledzenia promocji dla dowolnego systemu e-commerce.

Zastrzeżenie : Jestem współzałożycielem Voucherify. Chętnie odpowiem na Twoje pytania dotyczące projektowania i wdrażania promocji cyfrowych oraz oczywiście dotyczące naszego interfejsu API .

Wiemy już, jak je zdobyć z poprzedniego przykładu, więc skupmy się na stworzeniu vouchera:

1. Jak już powiedzieliśmy, zawsze powinniśmy zacząć od dokumentacji.
2. Przewodnik szybkiego startu mówi nam, aby uzyskać nasz klucz API.
   Uwaga : zamiast tworzyć konto, możesz użyć kluczy testowych z przewodnika szybkiego startu — za chwilę pokażemy Ci, jak to zrobić.
3. Zobaczmy teraz, jak stworzyć kupon rabatowy. W Voucherify ten rodzaj promocji jest przedstawiany jako „voucher”.
4. Z dokumentacji dowiesz się, że aby utworzyć kupon, musisz wywołać metodę POST do punktu końcowego /vouchers .
5. Utwórz nowe żądanie w Postman.
6. Zmień metodę na POST.
   

   

7. Wklej punkt końcowy Voucherify https://api.voucherify.io/v1/vouchers/ i kliknij Wyślij.
   

   

8. Och, pstryk, nie mamy uprawnień do wywołania tego punktu końcowego. Jak można się domyślić, musimy dostarczyć klucze API.
   
   Voucherify ma na to nieco inny sposób. Zamiast umieszczać je jako parametry zapytania, powinieneś umieścić je w nagłówkach. Jest to powszechne podejście, ponieważ w ten sposób łatwiej jest zaimplementować i obsługiwać klucze niż dołączać je jako parametry zapytania.
   
   Dodaj klucze jak na obrazku i kliknij Wyślij. Zauważ, że Voucherify wymaga dwóch kluczy. Oto te, których możesz użyć do celów tego samouczka:
   X-App-Id: 8a824b12-0530-4ef4-9479-d9e9b9930176 X-App-Token: 9e322bac-8297-49f7-94c8-07946724bcbc

   

9. Otrzymujemy kolejny komunikat o błędzie, tym razem mówi, że ładunek nie może być pusty.
   

   

   
   Czym do cholery jest ładunek? Tak jak w przypadku GET chcemy pobrać jakieś informacje, tak przy POST musimy coś wysłać, a wysyłana przez nas wiadomość nazywa się payload i jest to zazwyczaj plik JSON.
   
   Teraz Voucherify API narzeka, że ​​go nie podaliśmy, co oznacza, że ​​nie może utworzyć kuponu, ponieważ nie powiedzieliśmy, jaki rodzaj kuponu ma utworzyć. Co teraz? Powrót do dokumentów!
10. Sprawdźmy, jakich informacji potrzebuje ta prośba, aby się powiodła. Na liście widzimy wiele opcji.
    

    

    
    Jeden parametr (typ) jest wymagany, a drugi opcjonalny. Załóżmy, że będzie to zniżka 20%, dostępna dla pierwszych 100 klientów, która wygasa dzisiaj. Teraz musimy znaleźć parametry odpowiedzialne za te funkcje rabatowe i złożyć je razem w formacie niestabilnym dla Voucherify API. Jak widać na powyższych przykładach, notacja JSON, której należy użyć, wygląda tak:

     { "type":"DISCOUNT_VOUCHER", "discount":{ "percent_off":20.0, "type":"PERCENT" }, "expiration_date":"2018-12-03T23:59:59Z", "redemption":{ "quantity":100 }

11. Aby skonfigurować ładunek w Postman, wklej wiadomość JSON na karcie Body. Wybierz typ „surowy” i JSON z listy dostępnych formatów ładunku i potwierdź przyciskiem Wyślij.
    

    

12. Voila! Voucherify pomyślnie utworzył nasz kupon rabatowy 20% (ponieważ pracujemy z kontem testowym, wszystkie wygenerowane kody zaczynają się od prefiksu „voucherify.io-”). Zespół marketingowy może teraz udostępnić kod klientom, a Voucherify automatycznie go zweryfikuje za każdym razem, gdy przyjdą do Twojego sklepu, aby go wykorzystać.
    

    

    
    Ale skąd wiemy, że to udana prośba? Przede wszystkim widzimy, że Voucherify wysłał nam wiadomość, która według ich dokumentacji wygląda na poprawną odpowiedź API. Po drugie, Postman wyświetla status 200 OK — co oznacza, że ​​nasza prośba się powiodła. Dlaczego 200 i jaki jest status?

Kody stanu API i komunikaty o błędach

Większość interfejsów API, z którymi będziesz kiedykolwiek korzystać, będzie oparta na protokole HTTP. HTTP to protokół, który standaryzuje komunikację między różnymi aplikacjami klienckimi i serwerami w Internecie.

Jednym z kluczowych elementów HTTP są kody statusu. Dzięki zrozumieniu kodu statusu Ty (a właściwie systemy, które wdrażasz) możesz natychmiast stwierdzić, co się stało z Twoim żądaniem. Możliwe, że napotkasz jeden z najpopularniejszych kodów statusu, gdy wpiszesz niewłaściwy link — 404

Ale jest ich znacznie więcej, a użytkownicy końcowi zwykle ich nie widzą. Wynoszą one od 100+ do 500+. Ogólnie rzecz biorąc, liczby są zgodne z następującymi zasadami:

• 200+ oznacza, że ​​żądanie powiodło się;
• 300+ oznacza, że ​​żądanie jest przekierowywane na inny adres URL;
• 400+ oznacza, że ​​wystąpił błąd pochodzący z aplikacji klienckiej;
• 500+ oznacza, że ​​wystąpił błąd pochodzący z serwera.

Gdybyś mógł powtórzyć te kroki jeszcze raz, zobaczyłbyś, że Voucherify odpowiedział 401 Unauthorized, gdy nie dostarczyliśmy kluczy API. Lub 400 nieprawidłowych żądań, gdy nie było ładunku wymaganego do żądania utworzenia kuponu. Ostatecznie otrzymaliśmy 200 jako symbol pomyślnego wywołania API.

Jeśli interesuje Cię znaczenie kodów statusu HTTP, nie ma lepszego miejsca niż HTTP Cats (lub może ten artykuł).

Streszczenie

Rosnąca ilość danych i potrzeba szybkości w tworzeniu produktów sprawiły, że interfejsy API stały się lingua franca zespołów cyfrowych. Aby projektować systemy oparte na systemach API-first, upewnij się, że rozumiesz ofertę dostawców. Ten praktyczny przewodnik po testach jest dobrym punktem wyjścia. Pomoże Ci zbadać możliwości interfejsu API, jeszcze zanim wrzucisz je do swojego zespołu nauczycielskiego, oszczędzając jego energię — a także Twoją.

Dalsza lektura

• „Wprowadzenie do interfejsów API handlu elektronicznego dla nie-programistów”, Scott Brinker
• „Wyjdź poza Headless CMS — poznaj Headless Commerce”, Michał Sedzielewski, Voucherify
• „Jak korzystać z platform API-First, aby szybciej budować witryny internetowe”, Michał Sedzielewski, Medium
• „Jak wykorzystać platformę API-First, aby przygotować prototyp do produkcji”, Michał Sedzielewski, Medium
• „Jak wykorzystać chmurę do szybszego tworzenia aplikacji”, Michał Sedzielewski, Hacker Noon