Wprowadzenie

API to skrót od Application Programming Interface, i jest to nie­ste­ty bar­dzo mylą­ca nazwa. Dlaczego? Bo to nie jest ​„coś do pro­gra­mo­wa­nia”. API to po pro­stu usłu­ga apli­ka­cji udo­stęp­nia­na nie (ludz­kim) użyt­kow­ni­kom na ekra­nie kom­pu­te­ra, a innym aplikacjom. 

Dwa lata temu opi­sy­wa­łem pro­jek­to­wa­nie API i inte­gra­cji, pisa­łem też, dla­cze­go od inte­gra­cji obec­nie nie ma już ucieczki: 

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu infor­ma­tycz­ne­go. […] Czym jest obec­nie inte­gra­cja? To wymia­na danych a nie ich współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych w cza­sach obec­nych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

https://​it​-con​sul​ting​.pl/​2​0​2​2​/​0​2​/​2​1​/​i​n​t​e​g​r​a​c​j​a​-​j​a​k​o​-​z​r​o​d​l​o​-​p​r​z​e​w​a​g​i​-​r​y​n​k​o​w​e​j​-​c​z​y​l​i​-​j​a​k​-​p​r​o​j​e​k​t​o​w​a​c​-​r​e​s​t​-​a​p​i​-​z​-​v​i​s​u​a​l​-​p​a​r​a​d​i​gm/

Artykuł powyż­szy pole­cam oso­bom zain­te­re­so­wa­nym stro­ną tech­nicz­ną pro­jek­to­wa­nia inte­gra­cji i API. Dzisiaj odpo­wiem na pro­ble­my jakie zgła­sza­ją praw­ni­cy, czy­li co jest przed­mio­tem umo­wy gdy przed­mio­tem tym jest mitycz­ne API.

Aplikacja i jej API – co to takiego

Generalnie każ­da apli­ka­cja (kom­pu­te­ro­wy pro­gram użyt­ko­wy) świad­czy swo­im użyt­kow­ni­kom okre­ślo­ne usłu­gi, w nota­cji UML apli­ka­cja to «sys­tem». Użytkownikiem apli­ka­cji jest każ­dy zewnętrz­ny byt, mają­cy z tą apli­ka­cją inte­rak­cje, w nota­cji UML jest to aktor. Aktorem jest zarów­no nasz usłu­go­daw­ca jak i usłu­go­bior­ca. Jeżeli akto­rem jest czło­wiek, jako inter­fej­su uży­wa on GUI (Graphical User Interface). Jeżeli akto­rem jest apli­ka­cja, uży­wa ona API (Application Programming Interface). Ta nie­szczę­sna nazwa: pro­gram­ming inter­fa­ce, ma swój rodo­wód w tym, że adre­sa­tem opi­su tego inter­fej­su jest programista/projektant, a nie ludz­ki użyt­kow­nik aplikacji.

Poniższy dia­gram (dia­gram przy­pad­ków uży­cia nota­cji UML) obra­zu­je wyżej opi­sa­ne role:

Diagram ten poka­zu­je kon­tekst czy­li kto jest użyt­kow­ni­kiem i cze­go, dla­te­go poka­za­ne ele­men­ty róż­nią sie kształ­tem (róż­ne iko­ny). Jednak powyż­sza archi­tek­tu­ra, poka­za­na na dia­gra­mie kom­po­nen­tów, któ­ry nie nie­sie infor­ma­cji o kon­tek­ście ​„ja/ty”, wyglą­da tak:

Tak zwa­ne ​„lizacz­ki” na tym dia­gra­mie to inter­fej­sy ofe­ro­wa­ne, ​„klie­lisz­ki” to inter­fej­sy wyma­ga­ne. Tak więc API1 to: inter­fejs ofe­ro­wa­ny przez System Usługodawcy i jed­no­cze­śnie inter­fejs wyma­ga­ny przez System. API2 to inter­fejs ofe­ro­wa­ny przez System i jed­no­cze­śnie inter­fejs wyma­ga­ny przez System Usługobiorcy. GUI to inter­fejs ofe­ro­wa­ny przez System (ludz­kie­mu) Użytkownikowi. 

Co do zasa­dy, bez wzglę­du na to czy ofe­ro­wa­ny czy wyma­ga­ny, inter­fej­sy defi­niu­je­my jako:

• nazwa pole­ce­nia (opcja w menu użytkownika), 
• jego para­me­try,
• odpo­wiedź,
• struk­tu­ry para­me­trów i odpo­wie­dzi (for­mu­larz ekra­no­wy, komunikat).

Całość to zawsze dia­log: wywo­ła­nie usłu­gi z ewen­tu­al­nym para­me­trem, odpo­wiedź z ewen­tu­al­nym para­me­trem. Te para­me­try to dane, mogą być zebra­ne jako nazwa­ny komu­ni­kat i jego struk­tu­ra (zale­ca­ne). Ważne jest to, że tak na praw­de nie ma zna­cze­nia czy akto­rem jest czło­wiek czy apli­ka­cja, bo mecha­nizm gene­ro­wa­nia odpo­wie­dzi, reali­zo­wa­ny przez System, jest taki sam.

Widać to np. na poniż­szym dia­gra­mie poka­zu­ją­cym przy­kła­do­we wnę­trze aplikacji:

To czy apli­ka­cja będą­ca usłu­go­daw­cą jest w naszej ser­we­row­ni czy w chmu­rze, nie ma żad­ne­go znaczenia.

Prawnik zgłasza problem

Na por­ta­lu LinkedIn, poja­wia­ją sie róż­ne cie­ka­we wpi­sy, szcze­gól­nie cie­ka­we są te na sty­ku IT i pra­wa. Tym razem praw­nicz­ka zgła­sza problemy:

Obecnie duża część biz­ne­sów opie­ra się na pro­duk­tach API. Udostępnienie czy sprze­daż API nie jest dokład­nie jed­nak taka sama jak sprze­daż pro­duk­tu Software-as-a-Service lub licen­cjo­no­wa­ne­go opro­gra­mo­wa­nia. Istnieją pew­ne spe­cy­ficz­ne niu­an­se, któ­re muszą zostać umow­nie okre­ślo­ne w umo­wach licen­cyj­nych API.

[LINK do źródła]

📍Problem pierw­szy. Jak dobrze zde­fi­nio­wać czym jest API? I klucz API?

API to usłu­ga, klucz to hasło/kod dostę­pu do niej,

📍Problem dru­gi. Zakres udzie­la­nych licen­cjo­bior­cy praw

iden­tycz­ny jak dla czło­wie­ka: może korzy­stać albo nie, pozy­ska­na treść może być chro­nio­na innym pra­wem (np. API udo­stęp­nia­ją­ce eBooki),

📍Problem trze­ci. Zakres obo­wiąz­ków dostaw­cy API

iden­tycz­ny jak każ­de­go inne­go dostaw­cy opro­gra­mo­wa­nia,

📍Problem czwar­ty. Kod API infor­ma­cją pouf­ną czy nie?

nie ma żad­ne­go ​„kodu API”, jest kod apli­ka­cji (jest tak­że mecha­nizm dzia­ła­nia tej apli­ka­cji),

📍Problem pią­ty. Standardy bez­pie­czeń­stwa w korzy­sta­niu z API, potrzebne?

tak samo jak dla każ­dej apli­ka­cji,

📍Problem szó­sty. Zbieranie infor­ma­cji na temat korzy­sta­nia z API przez licen­cjo­bior­cę, potrzeb­na zgo­da czy nie?

tak samo jak zbie­ra­nie każ­dych innych sta­ty­styk, dodam, że użyt­kow­nik może sobie robić dowol­ne sta­ty­sty­ki po swo­jej stro­nie i niko­go nie musi pytać o zgo­dę na to,

📍Problem siód­my. Użytkownicy dal­si, jak oni korzy­sta­ją z API?

co to za cudo Ci ​„Użytkownicy dal­si”?

📍Problem ósmy. Czy umo­wę moż­na wypowiedzieć?

a dla­cze­go nie? Umowa jak każ­da inna,

📍Problem dzie­wią­ty. Przekazywanie danych poprzez API, potrzeb­na zgo­da użyt­kow­ni­ków apli­ka­cji czy nie?

nie da się uży­wać API nie prze­ka­zu­jąc danych 🙂

📍Problem dzie­sią­ty. Gwarancja na API, dawać czy nie dawać?

tak samo jak jak na każ­de opro­gra­mo­wa­nie,

📍Problem jede­na­sty. Odpowiedzialność, ogra­ni­czać? I co z odpo­wie­dzial­no­ścią za apli­ka­cje wyko­rzy­stu­ją­ce API?

nic, robią co chcą,

📍cacho­wa­nie, logo­wa­nie ruchu i wyjąt­ków dostę­pu, for­ward i rever­se pro­xy na dane dostęp­ne z API

to wewnętrz­ne funk­cje sys­te­mu a nie cecha API (SLA)

📍sand­box testo­wy API vs pro­duk­cyj­ny (moc­ko­wa­nie API)

to dodat­ko­wa ofer­ta, taka sama jak np. ​„testo­we uży­wa­nie ERP przez księ­go­wą”

📍SLA + healthChecki

jak wyżej

📍roz­li­cze­nie i moni­to­ro­wa­nie płat­no­ści / sub­skryb­cji dostę­pów do api + ogra­ni­cze­nia z tym zwią­za­ne: dostę­pu, ilo­ści wysła­nych i ode­bra­nych danych, pręd­kość wysy­ła­nia i odbie­ra­nia danych, prze­twa­rza­nie maso­we, mak­sy­mal­ne roz­mia­ry wysy­ła­nych i odbie­ra­nych danych, dopusz­czal­na ilość żądań/s, timeout‑y

jak wyżej

📍wali­da­cja i gwa­ran­cja popraw­no­ści danych (jed­no źró­dło prawdy)

a kto chce nie­po­praw­ne?

📍wer­sjo­no­wa­nie API, kom­pa­ty­bil­ność wstecz­na z ele­men­ta­mi ​„lega­cy API”

to jakoś sys­te­mu i jego dostaw­cy,

📍reten­cja danych

to wyma­ga­nie i cecha opro­gra­mo­wa­nia a nie cecha API.

Podsumuję to tak

„Udostępnienie czy sprze­daż API nie jest dokład­nie jed­nak taka sama jak sprze­daż pro­duk­tu Software-as-a-Service lub licen­cjo­no­wa­ne­go oprogramowania. ”

To nie jest praw­da, to jest to samo.

„Istnieją pew­ne spe­cy­ficz­ne niu­an­se, któ­re muszą zostać umow­nie okre­ślo­ne w umo­wach licen­cyj­nych API.”

to też nie jest praw­da, nie ist­nie­ją takie.

To co ist­nie­je, to opro­gra­mo­wa­nie, które:

- ofe­ru­je usłu­gi (funk­cjo­nal­no­ści)

- ofe­ru­je pewien poziom jako­ści (SLA) i kon­tro­li dostę­pu do niego.

tak jak każ­de oprogramowanie.

Prawnicy: nie zmy­ślaj­cie pro­ble­mów na siłę.