„Publiczne interfejsy API są wieczne: tylko jedna szansa, aby zrobić to dobrze”?

W książce o systemie operacyjnym właśnie przeczytałem: „Publiczne interfejsy API są wieczne: tylko jedna szansa, aby zrobić to dobrze”. Czy to prawda? Czy ma zastosowanie tylko w interfejsach API systemów operacyjnych lub innych interfejsach API? Na przykład, czy będzie tak w przypadku interfejsów API aplikacji na Androida, takich jak Tasker, Locale i Pushover?

Tak jest ogólnie w przypadku dowolnego publicznego interfejsu API, tak. Gdy udostępnisz interfejs API publicznie, a ludzie zaczną budować aplikacje zależne od tego interfejsu API, zmiana interfejsu API będzie niezwykle trudna, ponieważ spowoduje to uszkodzenie wszystkich tych aplikacji. Jest to zarówno trudny problem techniczny, jak i trudny problem polityczny.

Oczywiście można zmienić publiczny interfejs API. Zdarza się na przykład, że projekty osłabią interfejs API w jednej wersji, wprowadzą nowy interfejs API, a następnie usuną stary interfejs API w przyszłej wersji. Zakłada się jednak, że każda (ważna) aplikacja korzystająca ze starego interfejsu API zostanie przepisana w celu użycia nowego interfejsu API przed usunięciem starego interfejsu API. To często zajmuje wiele lat. A to oznacza, że ​​właściciel publicznego API nakłada koszty na każdy inny projekt korzystający z API. Ponieważ na ogół jest znacznie więcej konsumentów API, konsumenci ci są zwykle silnym lobby politycznym.

Autorem cytatu jest Joshua Bloch, oświadczenie pochodzi z artykułu Bumper-Sticker API Design :

Publiczne interfejsy API, takie jak diamenty, są wieczne. Masz jedną szansę, aby zrobić to dobrze, więc daj z siebie wszystko.

Aby uzyskać więcej informacji na ten temat, autor odsyła czytelników do prezentacji podczas sesji konferencyjnej „Jak zaprojektować dobry interfejs API i dlaczego to ma znaczenie” . Slajd Dlaczego projekt interfejsu API jest dla Ciebie ważny , dość wyraźnie stwierdza, że ​​ma to znaczenie dla każdej działalności programistycznej (systemy operacyjne czy nie, nie ma znaczenia dla autora):

• Jeśli programujesz, jesteś projektantem API

  • Dobry kod ma budowę modułową - każdy moduł ma interfejs API

• Przydatne moduły mają tendencję do ponownego wykorzystywania

  • Gdy moduł ma użytkowników, nie może dowolnie zmieniać interfejsu API
  • Dobre moduły wielokrotnego użytku są aktywami korporacyjnymi

• Myślenie w kategoriach API poprawia jakość kodu

Zjeżdżalnia Wnioski Podkreśla to również podejście ogólne:

• Projektowanie API jest szlachetnym i satysfakcjonującym rzemiosłem

  • Poprawia wielu programistów, użytkowników końcowych, firm ...

Interfejsy API zawsze się zmieniają, w przeciwnym razie jaki byłby sens aktualizacji systemu? Zmieniasz tylko elementy wewnętrzne?

Każda wersja systemu wprowadza nowe interfejsy API, stare interfejsy API stają się przestarzałe, a przestarzałe interfejsy API znikają.

Zmiana interfejsu API musi być bardzo ostrożna zarówno pod względem technicznym, jak i pod względem komunikacji.

Moja opinia byłaby taka, że ​​po wydaniu ta „wersja” interfejsu API jest na zawsze, ale można go przestać, wypuszczając interfejs API „2.0” (istnieje kilka przykładów, w których tak się dzieje - obecnie myślę o Strava, która wydała wersja 2.0 interfejsu API do programowania w celu korzystania z ich usług).

Problem polega na tym, że ta oryginalna API ad infinitum jest obsługiwana ... Myślę, że zależy to od użycia starego API i od tego, jaką wartość mają ci klienci API.

Wracając do „dawnych czasów”, powiedzmy Windows 3.xi 9x itd., Po wydaniu te interfejsy API systemu operacyjnego zostały wykonane i ustawione. Teraz aktualizacje systemu operacyjnego są wypychane przez cały czas, więc nowe interfejsy API mogą być wydawane, ale myślę, że dopóki używasz określonego systemu operacyjnego (wersja główna), te interfejsy API będą tylko dodawane, nigdy nie usuwane ... może nie niech tak będzie w przypadku „następnego” wydania głównego.

Hmmm, może zboczyłem z pierwotnego celu pytania.

To zależy od tego, jaki to jest interfejs API (i zakładam przełamywanie zmian, w przeciwnym razie stwierdzenie oczywiście nie jest prawdziwe).

Jeśli osoba dzwoniąca może wybrać używaną wersję (np. Z bibliotekami / strukturami dołączonymi do aplikacji wywołującej), zmiana interfejsu API nie stanowi dużego problemu - ale nadal szkodzi reputacji oprogramowania. Ludzie lubią bezproblemowo aktualizować.

Z drugiej strony, gdy ludzie nie mogą nadal korzystać ze starej wersji interfejsu API (na przykład z usługą online lub rzeczy takich jak przeglądarka lub system operacyjny, w których uruchamianie starych wersji jest bardzo niepożądane), zmiana interfejsów API w sposób niezgodny jest bardzo zła w istocie, ponieważ spowoduje to uszkodzenie całego oprogramowania, które z niego korzysta i również nie zostanie zaktualizowane. Nakłada to koszty utrzymania na programistów i będą cię za to nienawidzić. A oprogramowanie, które nie jest obsługiwane i nie działa prawidłowo, odbije się negatywnie na tobie.

Z drugiej strony jest co najmniej jeden dostawca interfejsu API, który stale wprowadza przełomowe zmiany w interfejsie API i mimo wszystko odnosi absurdalny sukces: Facebook. Ale bardzo ostrożnie zarządzają zmianami: istnieje opublikowana polityka , przełomowe zmiany są ogłaszane i wyjaśniane co najmniej 90 dni wcześniej, a programiści mogą zdecydować się na ich wczesną aktywację w tym czasie.

Jeśli masz przewidywanie, aby dołączyć numer wersji do samego interfejsu API. Zarówno w przypadku połączenia / inicjalizacji, jak i gdzieś na początku listy parametrów dla każdego połączenia, interfejs API może ewoluować i mutować w czasie, bez zakłócania działania istniejących klientów.

Chociaż wszystko, co robimy, polega na tym, aby uczynić ich najlepszymi za jednym razem, ale skoro nadchodzi zmiana czasu i poprawa, czasami musimy zaktualizować informacje, jak robiło to wielu gigantycznych dostawców (np. Kilka aktualizacji facebooka, twitter jeden główny przechodzę na oAuth i kilka głównych, ale co najwyżej możliwe, wszystko idzie z poprawą, więc nie ma częstych zmian. I tak, proszę, nie przestawaj wspierać starszych, to boli !! :)

Za każdym razem, gdy wydasz jakikolwiek protokół komunikacyjny, który oczywiście zawiera API, masz jedną szansę, aby uzyskać właściwy wynik w tym sensie, że protokół / interfejs musi być kompatybilny wstecz i rozszerzalny.

Pozwala to dodawać nowe funkcje i wydawać nowe wersje bez martwienia się o uszkodzenie osób korzystających ze starszych wersji. Nigdy w świecie oprogramowania nie będziesz miał takiej sytuacji, w której po prostu będziesz mieć twardy dysk w określonym momencie, a wszyscy porzucą starą wersję i zaczną używać nowej.