Wprowadzenie

API to skrót od Application Programming Interface, i jest to niestety bardzo myląca nazwa. Dlaczego? Bo to nie jest “coś do programowania”. API to po prostu usługa aplikacji udostępniana nie (ludzkim) użytkownikom na ekranie komputera, a innym aplikacjom.

Dwa lata temu opisywałem projektowanie API i integracji, pisałem też, dlaczego od integracji obecnie nie ma już ucieczki:

Mamy ogólnoświatową sieć Internet, aplikacje lokalne i w chmurze, aplikacje naszych kontrahentów i aplikacje centralnych urzędów. Wszystkie one współpracują i wymieniają dane, czyli są zintegrowane. Dlatego integracja stała się cechą każdego systemu informatycznego. […] Czym jest obecnie integracja? To wymiana danych a nie ich współdzielenie: dane z urzędem wymieniamy, dane z kontrahentem wymieniamy, nie współdzielimy żadnych danych z tymi podmiotami, każdy ma swoje własne, bezpieczne bazy danych, i to wszystko ładnie działa! Idea zbudowania wszystkich funkcjonalności jako zintegrowanej aplikacji na jednej współdzielonej bazie danych w czasach obecnych jest utopią. Taką samą jak hipotetyczna centralna baza danych dla wszystkich sklepów internetowych, firm kurierskich i banków, a one są jednak zintegrowane: one wymieniają dane a nie współdzielą!

https://it-consulting.pl/2022/02/21/integracja-jako-zrodlo-przewagi-rynkowej-czyli-jak-projektowac-rest-api-z-visual-paradigm/

Artykuł powyższy polecam osobom zainteresowanym stroną techniczną projektowania integracji i API. Dzisiaj odpowiem na problemy jakie zgłaszają prawnicy, czyli co jest przedmiotem umowy gdy przedmiotem tym jest mityczne API.

Aplikacja i jej API – co to takiego

Generalnie każda aplikacja (komputerowy program użytkowy) świadczy swoim użytkownikom określone usługi, w notacji UML aplikacja to ‘system’. Użytkownikiem aplikacji jest każdy zewnętrzny byt, mający z tą aplikacją interakcje, w notacji UML jest to aktor. Aktorem jest zarówno nasz usługodawca jak i usługobiorca. Jeżeli aktorem jest człowiek, jako interfejsu używa on GUI (Graphical User Interface). Jeżeli aktorem jest aplikacja, używa ona API (Application Programming Interface). Ta nieszczęsna nazwa: programming interface, ma swój rodowód w tym, że adresatem opisu tego interfejsu jest programista/projektant, a nie ludzki użytkownik aplikacji.

Poniższy diagram (diagram przypadków użycia notacji UML) obrazuje wyżej opisane role:

Diagram ten pokazuje kontekst czyli kto jest użytkownikiem i czego, dlatego pokazane elementy różnią sie kształtem (różne ikony). Jednak powyższa architektura, pokazana na diagramie komponentów, który nie niesie informacji o kontekście “ja/ty”, wygląda tak:

Tak zwane “lizaczki” na tym diagramie to interfejsy oferowane, “klieliszki” to interfejsy wymagane. Tak więc API1 to: interfejs oferowany przez System Usługodawcy i jednocześnie interfejs wymagany przez System. API2 to interfejs oferowany przez System i jednocześnie interfejs wymagany przez System Usługobiorcy. GUI to interfejs oferowany przez System (ludzkiemu) Użytkownikowi.

Co do zasady, bez względu na to czy oferowany czy wymagany, interfejsy definiujemy jako:

• nazwa polecenia (opcja w menu użytkownika),
• jego parametry,
• odpowiedź,
• struktury parametrów i odpowiedzi (formularz ekranowy, komunikat).

Całość to zawsze dialog: wywołanie usługi z ewentualnym parametrem, odpowiedź z ewentualnym parametrem. Te parametry to dane, mogą być zebrane jako nazwany komunikat i jego struktura (zalecane). Ważne jest to, że tak na prawde nie ma znaczenia czy aktorem jest człowiek czy aplikacja, bo mechanizm generowania odpowiedzi, realizowany przez System, jest taki sam.

Widać to np. na poniższym diagramie pokazującym przykładowe wnętrze aplikacji:

To czy aplikacja będąca usługodawcą jest w naszej serwerowni czy w chmurze, nie ma żadnego znaczenia.

Prawnik zgłasza problem

Na portalu LinkedIn, pojawiają sie różne ciekawe wpisy, szczególnie ciekawe są te na styku IT i prawa. Tym razem prawniczka zgłasza problemy:

Obecnie duża część biznesów opiera się na produktach API. Udostępnienie czy sprzedaż API nie jest dokładnie jednak taka sama jak sprzedaż produktu Software-as-a-Service lub licencjonowanego oprogramowania. Istnieją pewne specyficzne niuanse, które muszą zostać umownie określone w umowach licencyjnych API.

[LINK do źródła]

📍Problem pierwszy. Jak dobrze zdefiniować czym jest API? I klucz API?

API to usługa, klucz to hasło/kod dostępu do niej,

📍Problem drugi. Zakres udzielanych licencjobiorcy praw

identyczny jak dla człowieka: może korzystać albo nie, pozyskana treść może być chroniona innym prawem (np. API udostępniające eBooki),

📍Problem trzeci. Zakres obowiązków dostawcy API

identyczny jak każdego innego dostawcy oprogramowania,

📍Problem czwarty. Kod API informacją poufną czy nie?

nie ma żadnego “kodu API”, jest kod aplikacji (jest także mechanizm działania tej aplikacji),

📍Problem piąty. Standardy bezpieczeństwa w korzystaniu z API, potrzebne?

tak samo jak dla każdej aplikacji,

📍Problem szósty. Zbieranie informacji na temat korzystania z API przez licencjobiorcę, potrzebna zgoda czy nie?

tak samo jak zbieranie każdych innych statystyk, dodam, że użytkownik może sobie robić dowolne statystyki po swojej stronie i nikogo nie musi pytać o zgodę na to,

📍Problem siódmy. Użytkownicy dalsi, jak oni korzystają z API?

co to za cudo Ci “Użytkownicy dalsi”?

📍Problem ósmy. Czy umowę można wypowiedzieć?

a dlaczego nie? Umowa jak każda inna,

📍Problem dziewiąty. Przekazywanie danych poprzez API, potrzebna zgoda użytkowników aplikacji czy nie?

nie da się używać API nie przekazując danych 🙂

📍Problem dziesiąty. Gwarancja na API, dawać czy nie dawać?

tak samo jak jak na każde oprogramowanie,

📍Problem jedenasty. Odpowiedzialność, ograniczać? I co z odpowiedzialnością za aplikacje wykorzystujące API?

nic, robią co chcą,

📍cachowanie, logowanie ruchu i wyjątków dostępu, forward i reverse proxy na dane dostępne z API

to wewnętrzne funkcje systemu a nie cecha API (SLA)

📍sandbox testowy API vs produkcyjny (mockowanie API)

to dodatkowa oferta, taka sama jak np. “testowe używanie ERP przez księgową”

📍SLA + healthChecki

jak wyżej

📍rozliczenie i monitorowanie płatności / subskrybcji dostępów do api + ograniczenia z tym związane: dostępu, ilości wysłanych i odebranych danych, prędkość wysyłania i odbierania danych, przetwarzanie masowe, maksymalne rozmiary wysyłanych i odbieranych danych, dopuszczalna ilość żądań/s, timeout-y

jak wyżej

📍walidacja i gwarancja poprawności danych (jedno źródło prawdy)

a kto chce niepoprawne?

📍wersjonowanie API, kompatybilność wsteczna z elementami “legacy API”

to jakoś systemu i jego dostawcy,

📍retencja danych

to wymaganie i cecha oprogramowania a nie cecha API.

Podsumuję to tak

“Udostępnienie czy sprzedaż API nie jest dokładnie jednak taka sama jak sprzedaż produktu Software-as-a-Service lub licencjonowanego oprogramowania. “

To nie jest prawda, to jest to samo.

“Istnieją pewne specyficzne niuanse, które muszą zostać umownie określone w umowach licencyjnych API.”

to też nie jest prawda, nie istnieją takie.

To co istnieje, to oprogramowanie, które:

– oferuje usługi (funkcjonalności)

– oferuje pewien poziom jakości (SLA) i kontroli dostępu do niego.

tak jak każde oprogramowanie.

Prawnicy: nie zmyślajcie problemów na siłę.