API reiškia programų programavimo sąsają - koncepciją, kuri taikoma visur, pradedant komandinės eilutės įrankiais, baigiant įmonės „Java“ kodu ir baigiant „Ruby on Rails“ žiniatinklio programomis. API yra būdas programiškai sąveikauti su atskiru programinės įrangos komponentu ar ištekliu.
Jei nerašysite kiekvienos kodo eilutės nuo nulio, bendrausite su išoriniais programinės įrangos komponentais, kurių kiekvienas turi savo API. Net jei ką nors rašote visiškai nuo nulio, gerai suprojektuota programinė įranga turės vidines API, kurios padės tvarkyti kodą ir padaryti komponentus daugkartinio naudojimo. Ir yra daugybė viešųjų API, leidžiančių pasinaudoti kitur žiniatinklyje sukurtais funkcionalumais.
Kas yra API?
API apibrėžiama kaip galimos sąveikos su programinės įrangos komponentu specifikacija. Ką tai tiksliai reiškia? Na, įsivaizduokite, kad automobilis buvo programinės įrangos komponentas. Į jo API būtų įtraukta informacija apie ką tai gali padaryti - pagreitinti, stabdyti, įjungti radiją ir pan. Taip pat būtų informacijos apie kaip galėtum priversti tai daryti tuos dalykus. Pavyzdžiui, norėdami pagreitinti, uždėkite koją ant dujų pedalo ir stumiate.
API nereikia aiškinti, kas vyksta variklio viduje, kai dedi koją į akseleratorių. Štai kodėl, jei išmokote vairuoti automobilį su vidaus degimo varikliu, galite sėsti prie elektromobilio vairo nemokėdami visiškai naujų įgūdžių. ką ir kaip informacija pateikiama API apibrėžimas, kuris yra abstraktus ir atskiras nuo paties automobilio.
Reikėtų nepamiršti, kad kai kurių API pavadinimai dažnai naudojami sąveikos specifikacijoms ir tikram programinės įrangos komponentui, su kuriuo bendraujate, nurodyti. Pavyzdžiui, frazė „Twitter API“ nurodo ne tik programinio bendravimo su „Twitter“ taisyklių rinkinį, bet ir suprantama, kad tai reiškia dalyką, su kuriuo bendraujate, kaip skyrelyje „Mes analizuojame tweetus, iš kurių gavome „Twitter“ API. “
API kaip abstrakcijos sluoksnis
Kalbant apie programinę įrangą, API yra tiesiog visur. API eina kartu su viena pagrindinių informatikos sąvokų: abstrakcija. Abstrakcija yra tik būdas organizuoti sistemos sudėtingumą, kad sudėtingus veiksmus būtų galima atlikti paprastai. Pagalvokite apie šią abstrakciją kaip apie tuos „Amazon Dash Buttons“, su baterijomis valdomas, mygtukines plokštes, kuriomis galite užsisakyti kabes iš „Amazon“. Štai kaip jie atrodo:
Jūs užsisakote „Dash“ mygtuką iš „Amazon“ ir naudodamiesi savo išmaniojo telefono programa susiejate jį su „Wi-Fi“ tinklu, „Amazon“ paskyra ir, tarkime, jūsų mėgstamiausio popierinių rankšluosčių prekės ženklu. Tada, kai tik norite užsisakyti daugiau popierinių rankšluosčių, tiesiog paspauskite mygtuką. Mygtukas Brūkšnys prisijungia prie interneto ir siunčia pranešimą, kad jūsų paskyroje būtų pateiktas užsakymas. Po kelių dienų prie jūsų slenksčio atkeliauja popieriniai rankšluosčiai.
Kaip ir API, brūkšnio mygtukas yra palaimingai paprasta sąsaja, slepianti įvairius sudėtingumus užkulisiuose. Užsakyto produkto ID reikia gauti iš tam tikros duomenų bazės. Pristatymo adresą reikia pasiimti iš jūsų paskyros. Turi būti nustatytas artimiausias įvykdymo centras, kuriame laikomi popieriniai rankšluosčiai, tada pranešta, kad išimtų daiktą iš turimų atsargų ir supakuotų. Galiausiai, paketas turi būti nukreiptas per tam tikrą lėktuvų, sunkvežimių ir furgonų derinį kartu su kitais paketais taip, kad būtų užtikrinta, jog visi paketai efektyviai pasieks paskirties vietas.
Dabar įsivaizduokite, kad visus šiuos dalykus turėjote derinti kaip klientas. Niekada neužsisakysite popierinių rankšluosčių, nes tai per daug sudėtinga ir daug laiko užimantys dalykai. Laimei, visas išbandymas yra nutolęs nuo jūsų. Yra ilga, tarpusavyje susijusi kompiuterinių sistemų grandinė ir žmogaus procesai, dėl kurių tie popieriniai rankšluosčiai pasirodo prie jūsų namų slenksčio, tačiau tereikia galvoti apie vieno mygtuko paspaudimą.
Programuotojams tai yra API. Jie užima didžiulį sudėtingumą ir apibrėžia gana paprastą sąveikų rinkinį, kurį galite naudoti užuot viską atlikę patys. Bet kuriame programinės įrangos projekte tikriausiai naudojate dešimtis, jei ne šimtus API tiesiogiai, o kiekviena iš tų API priklauso nuo kitų API ir pan.
Viešosios API ir API integravimas
API yra sena kompiuterių programavimo koncepcija, ir jie daugelį metų buvo kūrėjų įrankių rinkinio dalis. Tradiciškai API buvo naudojamos prijungti toje pačioje mašinoje veikiančius kodo komponentus. Didėjant visuotiniam tinklui, vis daugiau viešosios API, kartais skambinama atviros API, tapo prieinami. Viešosios API yra nukreiptos į išorę ir prieinamos per internetą, leidžiančios internete rašyti kodą, sąveikaujantį su kitų tiekėjų kodu; šis procesas yra žinomas kaip API integracija.
Šios kodų rūšiavimo rūšys leidžia vartotojams maišyti ir suderinti skirtingų tiekėjų funkcijas savo sistemose. Pavyzdžiui, jei naudojate rinkodaros automatikos programinę įrangą „Marketo“, galite ten sinchronizuoti savo duomenis su „Salesforce CRM“ funkcijomis.
„Atviras“ ar „viešas“ šiame kontekste neturėtų būti aiškinamas kaip „nemokamas“. Kad tai veiktų, vis tiek turite būti „Marketo“ ir „Salesforce“ klientai. Tačiau dėl šių API prieinamumo integracija yra daug paprastesnis procesas, nei būtų kitaip. ( turi puikų viešųjų API sąrašą, apie kurį turėtumėte žinoti.)
Žiniatinklio paslaugos ir API
Galite prisiminti terminą web paslaugos nuo 00-ųjų pradžios ir manote, kad atviros API idėja skamba gana panašiai. Tiesą sakant, žiniatinklio paslauga yra tam tikra atviros API rūšis, kuri atitinka gana griežtą specifikacijų rinkinį, įskaitant tai, kad jos nurodomos žiniatinklio paslaugų aprašymo kalboje (WSDL), XML variante.
Žiniatinklio paslaugos turėjo būti naudojamos kaip į paslaugas orientuotos architektūros (SOA) dalis. Kaip paaiškinama „Nordic APIs“ tinklaraštyje, tai suteikė interneto paslaugoms blogo vardo, nes SOA niekada neišnaudojo savo galimybių. Paslaugų ir paslaugų ryšių metodų pažanga - ypač lengvesnė, lankstesnė REST - taip pat šiek tiek paliko žiniatinklio paslaugas viešųjų API pasaulyje.
REST API
Iš pradžių žiniatinklio paslaugos buvo sukurtos bendrauti naudojant SOAP (paprastą objekto prieigos protokolą) - pranešimų siuntimo protokolą, kuris siunčia XML dokumentus per HTTP. Tačiau šiandien dauguma internetinių API kaip architektūros stilių naudoja REST - „Reprezentacinės valstybės perkėlimą“.
„REST“ oficialiai pristatė Roy Fieldingas savo daktaro disertacijoje 2000 m. Tai yra architektūrinių komponentų, projektavimo principų ir sąveikos rinkinys, naudojamas kuriant paskirstytas sistemas, kuriose dalyvauja bet kokios rūšies laikmenos (tekstas, vaizdo įrašai ir kt.). Savo esme REST yra sistemų kūrimo stilius, leidžiantis lanksčiai bendrauti ir rodyti informaciją internete, kartu suteikiant struktūrą, reikalingą lengvai sukurti bendros paskirties komponentus.
REST API, a išteklių gali būti beveik bet kas, bet pavyzdžiai apima vartotoją, „tweets“ sąrašą ir dabartinius „tweet“ paieškos rezultatus. Kiekvienas iš šių šaltinių adresuojamas a išteklių identifikatorius, kuris žiniatinklio REST API atveju paprastai yra URL, pvz., //api.twitter.com/1.1/users/show?screen_name=twitterdev. Kai programa reikalauja išteklių, naudodama identifikatorių, API pateikia srovę atstovavimas to šaltinio programai tokiu formatu, kurį programa gali suvartoti, pavyzdžiui, JPEG paveikslėlis, HTML puslapis arba JSON.
Vienas iš didžiųjų REST skiriamųjų elementų yra tai, kad jis apima duomenų siuntimą į prašančią programą. Nors tai suteikia didelį lankstumą, leidžiant programai daryti viską, ko nori, naudojant duomenis, tai kainuoja efektyvumu. Duomenų siuntimas per internetą apdoroti yra gana lėtas, palyginti su apdorojimu ten, kur yra duomenys, ir tada siunčiami rezultatai.
Žinoma, „efektyvaus“ požiūrio problema yra ta, kad sistemoms, kuriose laikomi duomenys, iš anksto reikia žinoti, ką programos nori su jais daryti. Taigi, norint sukurti API, turinčią bendro naudojimo patogumą ir lankstumą, REST yra kelias.
API pavyzdžiai
Yra daugybė viešųjų API, su kuriomis galite bendrauti, daugelis iš jų yra iš pramonės begemotų. Galimybė programiškai pasiekti kai kurios platformos įmonės kodą per API yra tai, kas iš esmės daro jas platforma. Keli žinomi API pavyzdžiai:
- „Google“ API, kurie leidžia susieti kodą su visomis „Google“ paslaugomis, pradedant žemėlapiais ir baigiant vertėjais. API yra tokios svarbios „Google“, kad jie įsigijo „Apigee“, pirmaujančią API valdymo platformą.
- „Facebook“ API, kurie leidžia programiškai pasiekti „Facebook“ socialinius grafikus ir rinkodaros įrankius. („Cambridge Analytica“ ir kitų skandalų metu bendrovė apribojo tik tuos vartotojo duomenis, kuriuos galite pasiekti per šias API.)
Norėdami iš tikrųjų suvokti, kaip veikia API, giliai pasinerkime į du: „Java“ API, kurią „Java“ kūrėjai naudoja sąveikai su „Java“ platforma, ir „Twitter“ API, viešą API, kurią naudotumėte sąveikai su socialiniais tinklais. tinklo paslauga.
„Java“ API
„Java“ API yra programinės įrangos komponentų biblioteka, „prieinama“ visiems, kurie įdiegė „Java“ kūrimo rinkinį. Šie komponentai įgyvendina bendras užduotis ir paprastai padidina produktyvumą, nes programuotojams nereikia kiekvieną kartą pradėti nuo nulio. Vienas pagrindinių programinėje įrangoje naudojamų komponentų yra sąrašas, vadinamas „Sąrašu“, kuris, kaip ir galima tikėtis, stebi daiktų sąrašą. „Java“ API apibrėžia ką galite padaryti su sąrašu: pridėti elementų, rūšiuoti sąrašą, nustatyti, ar elementas yra sąraše, ir tt Jis taip pat nurodo kaip atlikti tuos veiksmus. Norėdami rūšiuoti sąrašą, turite nurodyti, kaip norite rūšiuoti sąrašą: abėcėlės, skaičiaus mažėjimo, ryškiausios iki bukiausios spalvos ir kt.
„Twitter“ API
„Twitter“ API yra žiniatinklio JSON API, leidžianti kūrėjams programiškai sąveikauti su „Twitter“ duomenimis. Skirtingai nuo „Java“ API, kuri yra įtraukta į „Java“ kūrimo rinkinį, „Twitter“ API yra žiniatinklio API. Prie jo reikia prisijungti internetu teikiant „Twitter“ teikiamų paslaugų užklausas.
Naudodama žiniatinklio API, pvz., „Twitter“, jūsų programa siunčia HTTP užklausą, kaip tai daro žiniatinklio naršyklė. Tačiau užuot pateikęs atsakymą kaip tinklalapį, žmogus supranta, kad jis pateikiamas tokiu formatu, kurį programos gali lengvai išanalizuoti. Tam tikslui yra įvairių formatų, o „Twitter“ naudoja populiarų ir lengvai naudojamą formatą, vadinamą JSON. (Jei nesate susipažinę su JSON, galbūt norėsite praleisti kelias minutes, skaitydami jį čia.)
Vienas pagrindinių „Twitter“ elementų yra „Twitter“. „Twitter“ API jums tai sako ką galite daryti su „tweetais“: ieškoti „tweet“, sukurti „tweet“, įtraukti mėgstamą „tweet“. Tai taip pat jums sako kaip atlikti šiuos veiksmus. Norėdami ieškoti „tweets“, turite nurodyti savo paieškos kriterijus: terminus ar žymas su grotelėmis, kurių ieškote, geografinę vietą, kalbą ir kt.
API dizainas
API dizainas yra procesas, kurio metu formuluojamas API „kas“ ir „kaip“. Kaip ir viskam, ką galima sukurti, API projektavimui skiriamas skirtingas mąstymo ir priežiūros lygis, dėl kurio skiriasi API kokybės lygiai. Gerai sukurtos API elgiasi nuosekliai, atsižvelgia į jų kontekstą ir nepamiršta savo vartotojų poreikių.
Nuoseklus elgesys API labai įtakoja jo išmokimo greitį ir tikimybę, kad programuotojai jį naudodami padarys klaidų. Paprastai panašius veiksmus atliekančios API turėtų elgtis panašiai, neatsižvelgiant į jų techninius skirtumus. Nenuoseklaus API pavyzdžio ieškokime dviejų būdų, kaip pridėti elementą į „Java“ sąrašą:
Nors du elementų įtraukimo į sąrašą metodai daro tą patį, jų grąžinimo tipai (loginiai ir negaliojantys) skiriasi. Kūrėjai, naudojantys šią API, dabar turi stebėti, kuris metodas grąžina kokį tipą, todėl API yra sunkiau išmokti, o jos naudojimas labiau linkęs į klaidas. Tai taip pat reiškia, kad kodas, kuris naudoja šiuos metodus, tampa ne toks lankstus, nes jis turi pasikeisti, jei norite pakeisti elementų pridėjimo būdą.
Atsižvelgimas į kontekstą yra dar viena nuoseklumo forma, nors tai susiję su išoriniais API veiksniais. Puikus, ne programinės įrangos pavyzdys yra tai, kaip kelių eismo taisyklė - eismas dešine ar kairėn - daro įtaką automobilių dizainui skirtingose šalyse. Automobilių dizaineriai atsižvelgia į šį aplinkos veiksnį nustatydami vairuotojo sėdynę dešinėje ar kairėje automobilio pusėje.
