Sposób myślenia platformy w zarządzaniu produktami API

Nie jest tajemnicą, że pandemia znacznie zwiększyła potrzebę przyjęcia przez organizacje strategii digital-first. Cyfrowe transformacje, które zostały pozbawione priorytetów na rzecz innych celów organizacyjnych, przesunęły się na pierwszy plan z dnia na dzień, z bezprecedensową pilnością. Zgodnie z globalnym badaniem kadry kierowniczej McKinsey z 2020 r. firmy przyspieszyły tempo, w jakim dokonały cyfryzacji operacji wewnętrznych i powiększyły portfolio produktów cyfrowych o kilka lat, pomimo znaczących wyzwań związanych z COVID-19.

Sercem tych cyfrowych transformacji jest integracja, którą ułatwiają interfejsy programowania aplikacji (API). Interfejsy API, niegdyś uważane po prostu za „posłańców” lub „pośredników”, którzy przesyłają dane między systemami oprogramowania, są obecnie uznawane za „tkankę łączną” ekosystemów cyfrowych, oferującą nieograniczoną integrację i możliwości biznesowe organizacjom, które je tworzą i wykorzystują. Ze względu na unikalny potencjał, jaki reprezentują interfejsy API, menedżerowie produktu nadzorujący ich rozwój muszą przyjąć podejście, które odblokuje ich ukrytą wartość, takie, które kładzie nacisk na elastyczność i rozszerzalność, aby zapewnić bezbłędną integrację.

Zrobić więcej za mniej

Jeszcze przed minionym, bezprecedensowym rokiem, wartość API dla organizacji była dobrze udokumentowana, a gospodarka API kwitła już od jakiegoś czasu. Aby zrozumieć dzisiejszy krajobraz integracji, warto zbadać początki filozofii Best of Breed (BoB). Przed latami 90. dostawcy oprogramowania sprzedawali rozwiązania z zakresu planowania zasobów przedsiębiorstwa (ERP), które próbowały rozwiązać wiele różnych wyzwań organizacyjnych. Coraz częściej te pakiety zaczęły być postrzegane jako nieporęczne i niepraktyczne, ponieważ nie uwzględniały przypadków użycia w danej organizacji. W rezultacie dostawcy zaczęli tworzyć bardziej ukierunkowane narzędzia, które rozwiązywały wyzwania dla jednego obszaru funkcjonalnego, zamiast większych pakietów, które próbowały zrobić wszystko dla wszystkich. Przedsiębiorstwa z zadowoleniem przyjęły pomysł wyboru spośród wielu mniejszych, bardziej wyspecjalizowanych narzędzi i zaczęły tworzyć kolekcje indywidualnych rozwiązań, które najlepiej odpowiadały ich konkretnym potrzebom.

Łączenie kropek

Gdy podejście BoB nabrało rozpędu, integracje stały się kluczowym elementem strategii produktowych. Narzędzie, które świetnie sprawdzało się w rozwiązywaniu problemów w jednym obszarze firmy, musiało dobrze integrować się z innymi produktami BoB, które prawdopodobnie będą używane razem z nim. Rozważ HubSpot, oprogramowanie sprzedażowe i CRM wdrażane przez organizacje w celu śledzenia i optymalizacji ich lejków sprzedaży i relacji z klientami. HubSpot łatwo integruje się z innym oprogramowaniem BoB, takim jak DocuSign (podpisy cyfrowe), Twilio (powiadomienia e-mail/SMS) i Zendesk (obsługa klienta) bez konieczności dodatkowego rozwoju ze strony zespołów inżynierskich klienta.

Potrzebie komplementarnych narzędzi do płynnego łączenia się ze sobą towarzyszyła ogólnobranżowa zmiana w kierunku otwartości zamiast ograniczania interakcji między systemami. Gdzieś po drodze liczba integracji obsługiwanych przez produkt stała się miernikiem wartym marketingu.

Propozycja platformy

Prawdziwa wartość integracji wykracza jednak poza ich zdolność do koordynowania różnych narzędzi i systemów. W najlepszym przypadku interfejsy API są zbiorowym mechanizmem przekształcania produktów w platformy. Produkty z definicji to narzędzia, które mają określone zastosowanie; stąd „aplikacje”. Mają ograniczone możliwości tworzenia wielu propozycji wartości, a co za tym idzie, wielu strumieni przychodów. Z drugiej strony platformy dodają wartość w inny sposób: zapewniając warstwę infrastruktury, na której można budować wiele produktów.

Interfejsy API otwierają nowe kanały biznesowe, korzystając z wiedzy osób trzecich, które je wykorzystują. Konsumenci mogą zaprojektować aplikację do obsługi nieruchomości, która korzysta z interfejsów API Miejsc Map Google, aby pomóc użytkownikom w szukaniu domów, lub mogą wykorzystać interfejsy API lotu Skyscanner i interfejsy API hotelu Expedia, aby stworzyć witrynę ekoturystyczną, która specjalizuje się w podróżach do określonej lokalizacji. Ci programiści i partnerzy zewnętrzni czerpią korzyści, uzyskując dostęp do istniejących danych i usług, które mogą dostosować do swoich firm, a właściciele interfejsów API, tacy jak Expedia, poszerzają swój zasięg i zarabiają na możliwościach, które nie istniałyby, gdyby nadal, powiedzmy, wyświetlali tylko hotele w swoich produktach.

Tworzenie modułowych

Dla liderów produktów opracowanie skutecznej strategii API wymaga zmiany sposobu myślenia z myślenia produktowego na myślenie platformowe. Oznacza to budowanie produktów w modułowy, otwarty sposób, który pozwala na rekombinację ich funkcjonalności i który priorytetowo traktuje elastyczność dla programistów. Pomyśl o systemach regałów IKEA, które klienci mogą kupować, montować i dostosowywać na różne sposoby, aby spełnić różnorodne potrzeby. Dobrzy menedżerowie produktów API widzą API takimi, jakimi są: narzędziami do skalowania biznesu i rozwijania wartościowych partnerstw. Uznanie tego potencjału oznacza wdrożenie najlepszych praktyk w celu zapewnienia adopcji.

Zachwycając programistów

Jeśli istnieje jeden fundamentalny filar solidnej strategii API, jest nim doświadczenie programisty (DX). W przypadku integracji API, menedżerowie produktu „klienci”, którzy muszą się cieszyć, to konsumujący programiści. Są to użytkownicy, którzy ostatecznie wywołują/integrują się z interfejsem API, potencjalni partnerzy, którzy mogą pomóc w realizacji wizji między produktem a platformą. Nazywanie ich doświadczenia „DX” zamiast „UX” oznacza, że ​​nie są oni typowymi użytkownikami końcowymi — są znacznie bardziej biegli technicznie. Aby wczuć się w nich, konieczne jest zrozumienie ich specyficznych potrzeb i oczekiwań.

Najlepsze praktyki

Poniższe, choć w żadnym wypadku nie stanowią wyczerpującej listy, są podstawowymi praktykami tworzenia pierwszorzędnych interfejsów API, które zapewniają bezproblemową i spójną, przewidywalną integrację dla programistów korzystających z usług. Menedżerowie produktu powinni podejść do projektowania interfejsów API w sposób skalowalny, zdefiniować ramy najlepszych praktyk i opublikować je jako dokument, do którego zespoły mogą się odwoływać podczas tworzenia nowych interfejsów API.

Spójne konwencje nazewnictwa i punkty końcowe

Ustanowienie spójnych konwencji nazewnictwa dla punktów końcowych API, które jasno identyfikują naturę i cel API, usuwa niejednoznaczność i przyczynia się do pozytywnego i przewidywalnego DX. Najlepiej wybrać wspólny podstawowy adres URL dla wszystkich interfejsów API i strukturę końcowego adresu URL, która unika żargonu i skrótów. Skandynawskie interfejsy API oferują przydatną listę wskazówek dotyczących nazewnictwa punktów końcowych.

Szczegółowe struktury odpowiedzi na sukces i niepowodzenie

Deweloperzy chcą i oczekują znanych obiektów danych i kodów stanu w celu uzyskania odpowiedzi o powodzeniu i niepowodzeniu. Oznacza to kod stanu 2xx dla scenariuszy powodzenia, kod 4xx dla błędów po stronie klienta i kod 5xx dla błędów po stronie serwera. Kluczowa jest jednak specyfika. Wywołanie API „wyślij wiadomość e-mail”, które po prostu zwraca odpowiedź 4xx bez dodatkowych informacji, pogarsza wrażenia programistów, ponieważ potwierdza jedynie, że błąd wystąpił w żądaniu klienta, bez podawania dodatkowych informacji o tym, co dokładnie poszło nie tak.

 { "status": 400, "message": "incorrect request" }

W przeciwieństwie do tego odpowiedź, która oferuje określone szczegóły w formacie czytelnym dla człowieka i w postaci unikalnego kodu błędu, może pomóc programistom szybko zdecydować, jak naprawić scenariusz błędu, napisać kod rozwiązujący problem i ponowić wywołanie interfejsu API.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Aby uzyskać optymalny DX, struktury odpowiedzi i klucze komunikujące status powinny być spójne we wszystkich interfejsach API. Na przykład pole kodu błędu w powyższym powinno być zawsze określane jako „kod” w każdym interfejsie API, a nie „kod” w niektórych interfejsach API i „errorCode” w innych.

Konfigurowalne limity stawek

Limity szybkości określają dostępność interfejsu API, określając, ile razy użytkownik może go wywołać w jednej jednostce czasu. Zbyt wysokie limity szybkości mogą zalewać systemy niewyobrażalną liczbą żądań, które obniżają wydajność, podczas gdy zbyt niskie limity szybkości mogą powodować kolejkowanie oczekujących transakcji w systemach użytkowników. Oba przyczyniają się do słabego DX-a. Podczas projektowania interfejsów API najlepiej jest uwzględnić limity szybkości, które można dostosować na podstawie konkretnych przypadków biznesowych i okoliczności. Na przykład klienci o dużym wolumenie mogą mieć rzeczywistą potrzebę częstszego wywoływania interfejsów API.

Aby jak najlepiej określić odpowiednie limity szybkości, warto najpierw pogrupować interfejsy API w znaczące kategorie zgodnie z częstotliwością i głośnością, z jaką są wywoływane. Na przykład interfejsy API, które konfigurują podstawowe dane klienta (tworzenie profilu/konta) są wywoływane rzadziej i mogą obsługiwać niższe limity stawek, podczas gdy interfejsy API transakcji („utwórz zamówienie”, „wyślij wiadomość e-mail”) są wywoływane częściej, co wymaga wyższych limitów stawek. Ustanowienie kategorii lub warstw dla różnych przypadków użycia zapewnia bardziej niezawodne i skalowalne interfejsy API. Aby zapoznać się z przykładem jasno zdefiniowanych limitów szybkości, zobacz dokumentację API Slacka.

Kompleksowa dokumentacja

Dokumentacja służy jako podręcznik użytkownika dla API. Wyraźnie przedstawia programistom, co robi API, jak z niego korzystać i czego się po nim spodziewać. Dobra dokumentacja jest napisana jasnym, przystępnym językiem, jest szczegółowa i interaktywna oraz oferuje wiele wersji demonstracyjnych i fragmentów kodu, aby ułatwić integrację. W ten sposób ułatwia on łatwe wdrażanie i szybki czas do pierwszego powitania w świecie (TTFHW), ważny wskaźnik, który pokazuje, jak szybko programista może pomyślnie wywołać swój pierwszy interfejs API.

Dokumentacja powinna jasno określać, które pola w żądaniu API są obowiązkowe, a które opcjonalne, a także minimalną i maksymalną długość oraz typ danych dla tych pól. Zasadniczo powinien zawierać wszystko, co niezbędne do ustalenia oczekiwań i usunięcia przeszkód dla konsumujących programistów. Deweloperzy tworzący na przykład schematy baz danych w swoich systemach nie powinni być zmuszeni później dopasowywać długości kolumn w tabelach, ponieważ dokumentacja nie określała parametrów.

Dokumentacja API może zwiększyć popularność nie tylko jako wiarygodne źródło informacji dla programistów, ale także jako narzędzie marketingowe dla samego API. Często pierwszą osobą, która styka się z dokumentacją API, jest interesariusz biznesowy, który przegląda ją w początkowej fazie oceny produktu. Powinna ona zatem zawierać nie tylko szczegółowe informacje na temat elementów technicznych interfejsu API, ale także jasno przedstawiać biznesowe przypadki użycia, które umożliwia interfejs API.

Na rynku istnieje szereg narzędzi, które mogą pomóc w generowaniu kompleksowej dokumentacji API. Pomocne jest również przeglądanie przykładów dokumentacji wysokiej jakości, takich jak Stripe.

Łącząc to wszystko razem

Integracje stanowią rozległą domenę z wieloma komponentami, ale zrozumienie podstawowych zasad dobrego interfejsu API ma fundamentalne znaczenie dla opracowania solidnej strategii. Interfejsy API to znacznie więcej niż zwykłe złącza systemowe. Są budulcem ekspansywnych sieci cyfrowych i kluczem do otwarcia nowych strumieni przychodów i uwolnienia niewykorzystanej wartości. Z tego powodu skuteczna strategia API to nie tylko tworzenie produktów; chodzi o budowanie potencjału. Menedżer produktu API musi przyjąć sposób myślenia o platformie i ustalić priorytety dla czynników, które zapewnią płynną adaptację dla potencjalnych partnerów, którzy będą mogli następnie zintegrować swój interfejs API i z nim pracować.