API apzīmē lietojumprogrammu saskarni - koncepciju, kas attiecas visur, sākot no komandrindas rīkiem līdz uzņēmuma Java kodam un beidzot ar tīmekļa lietotnēm Ruby on Rails. API ir veids, kā programmatiski mijiedarboties ar atsevišķu programmatūras komponentu vai resursu.
Ja vien jūs nerakstīsit katru koda rindiņu no nulles, jūs mijiedarbosities ar ārējiem programmatūras komponentiem, kuriem katram ir savs API. Pat ja jūs kaut ko pilnībā rakstāt no nulles, labi izstrādātai programmatūras lietojumprogrammai būs iekšējas API, kas palīdzēs sakārtot kodu un padarīt komponentus vairākkārt izmantojamus. Un ir daudz publisku API, kas ļauj jums izmantot funkcionalitāti, kas ir izstrādāta citur tīmeklī.
Kas ir API?
API ir definēta kā iespējamās mijiedarbības ar programmatūras komponentu specifikācija. Ko tas precīzi nozīmē? Nu, iedomājieties, ka automašīna bija programmatūras sastāvdaļa. Tās API ietvertu informāciju par kas tas var darīt - paātrināt, bremzēt, ieslēgt radio utt. Tas ietvertu arī informāciju par kā jūs varētu likt tai darīt tās lietas. Piemēram, lai paātrinātu, jūs uzliekat kāju uz gāzes pedāļa un nospiežat.
API nav jāpaskaidro, kas notiek motora iekšpusē, kad pieliekat kāju uz akseleratora. Tāpēc, ja iemācījāties vadīt automašīnu ar iekšdedzes motoru, varat sēsties pie elektromobiļa stūres, neapgūstot pilnīgi jaunas prasmes. The kas un kā informācija tiek apkopota API definīcija, kas ir abstrakts un atdalīts no pašas automašīnas.
Viena lieta, kas jāpatur prātā, ir tas, ka dažu API nosaukumus bieži lieto, lai atsauktos gan uz mijiedarbības specifikācijām, gan uz faktisko programmatūras komponentu, ar kuru mijiedarbojaties. Frāze “Twitter API”, piemēram, attiecas ne tikai uz noteikumu kopumu programmatiskai mijiedarbībai ar Twitter, bet parasti tiek saprasta kā lieta, ar kuru jūs mijiedarbojaties, tāpat kā sadaļā “Mēs analizējam tos tvītus, no kuriem saņēmām Twitter API. ”
API kā abstrakcijas slānis
Runājot par programmatūru, API ir burtiski visur. API iet roku rokā ar vienu no fundamentālākajiem datorzinātņu jēdzieniem: abstrakciju. Abstrakcija ir tikai veids, kā organizēt sistēmas sarežģītību tā, lai sarežģītas darbības varētu veikt vienkārši. Padomājiet par šo abstrakciju tāpat kā tās Amazon Dash Buttons, ar akumulatoru darbināmās, spiedpogas shēmas plates, kuras varat izmantot, lai pasūtītu skavas no Amazon. Šādi viņi izskatās:
Jūs pasūtāt Dash pogu no Amazon un izmantojat viedtālruņa lietotni, lai to saistītu ar savu Wi-Fi tīklu, savu Amazon kontu un produktu, teiksim, iecienītāko zīmolu papīra dvieļiem. Tad, kad vēlaties pasūtīt vairāk papīra dvieļu, vienkārši nospiediet pogu. Poga Dash izveido savienojumu ar internetu un nosūta ziņojumu, lai veiktu pasūtījumu jūsu kontā. Dažas dienas vēlāk pie jūsu sliekšņa nonāk papīra dvieļi.
Tāpat kā API, arī Dash Button ir svētlaimīgi vienkāršs interfeiss, kas aiz ainas slēpj visa veida sarežģītību. Pasūtītā produkta ID ir jāizgūst no kādas datu bāzes. Jūsu piegādes adrese ir jāizņem no konta. Ir jānosaka tuvākais izpildes centrs, kurā atrodas jūsu papīra dvieļi, un pēc tam jāinformē, lai izņemtu priekšmetu no pieejamajiem krājumiem un iesaiņotu. Visbeidzot, pakete jāpārvieto caur kādu lidmašīnu, kravas automašīnu un furgonu kombināciju kopā ar citām pakām tā, lai nodrošinātu, ka visas pakas efektīvi sasniegs galamērķi.
Tagad iedomājieties, ka visas šīs lietas jums bija jākoordinē kā klientam. Jūs nekad nepasūtīsit papīra dvieļus, jo tas ir pārāk sarežģīti un laikietilpīgi, un jums ir labākas lietas. Par laimi, viss pārbaudījums tiek atdalīts no jums. Ir gara, savstarpēji saistīta datorsistēmu un cilvēku procesu ķēde, kas liek šiem papīra dvieļiem parādīties pie jūsu sliekšņa, bet jums ir jādomā tikai par pogas nospiešanu.
Tas ir tas, ko API ir programmētājiem. Tie prasa ārkārtīgi daudz sarežģītības un definē salīdzinoši vienkāršu mijiedarbību kopumu, kuru varat izmantot, nevis darīt visu pats. Jebkurā programmatūras projektā jūs, visticamāk, izmantojat desmitiem, ja ne simtiem API tieši, un katra no šīm API balstās uz citām API un tā tālāk.
Publiskās API un API integrācija
API ir sena datorprogrammēšanas koncepcija, un tie jau gadiem ilgi ir daļa no izstrādātāju rīkkopas. Tradicionāli API tika izmantoti, lai savienotu kodu komponentus, kas darbojas vienā mašīnā. Pieaugot visuresošajam tīklam, arvien vairāk publiskās API, dažreiz sauc atvērtas API, ir kļuvuši pieejami. Publiskās API ir vērstas uz āru un pieejamas internetā, ļaujot tiešsaistē rakstīt kodu, kas mijiedarbojas ar citu piegādātāju kodu; šis process ir pazīstams kā API integrācija.
Šāda veida kodu sajaukumi ļauj lietotājiem sajaukt un saskaņot dažādu piegādātāju funkcionalitāti viņu pašu sistēmās. Piemēram, ja izmantojat mārketinga automatizācijas programmatūru Marketo, tur varat sinhronizēt savus datus ar Salesforce CRM funkcionalitāti.
Šajā kontekstā “atvērts” vai “publisks” nav jāinterpretē kā “bez maksas”. Lai tas darbotos, jums joprojām ir jābūt Marketo un Salesforce klientam. Bet šo API pieejamība padara integrāciju daudz vienkāršāku procesu, nekā tas būtu citādi. ( ir lielisks publisko API saraksts, par kuriem jums vajadzētu zināt.)
Tīmekļa pakalpojumi un API
Jūs varētu atcerēties terminu web pakalpojumi un domājiet, ka atvērtās API ideja izklausās diezgan līdzīga. Faktiski tīmekļa pakalpojums ir īpaša veida atvērta API, kas atbilst diezgan stingrai specifikāciju kopai, ieskaitot to, ka tās tiek norādītas Web Services Description Language (WSDL), XML variantā.
Tīmekļa pakalpojumus bija paredzēts izmantot kā daļu no uz pakalpojumu orientētas arhitektūras (SOA). Kā skaidro Nordic APIs emuārs, tas tīmekļa pakalpojumiem deva kaut ko sliktu, jo SOA nekad nav pilnībā izmantojis viņu potenciālu. Tehnoloģiju attīstība, kas tiek izmantota komunikācijai starp pakalpojumiem - īpaši vieglāka, elastīgāka REST -, arī publisko API pasaulē nedaudz atstājusi tīmekļa pakalpojumus.
REST API
Tīmekļa pakalpojumi sākotnēji tika veidoti, lai sazinātos, izmantojot SOAP (vienkāršo objektu piekļuves protokolu) - ziņojumapmaiņas protokolu, kas sūta XML dokumentus, izmantojot HTTP. Tomēr šodien lielākā daļa tīmekļa API izmanto arhitektūras stilu REST - reprezentatīvā stāvokļa pārsūtīšana.
Ar REST oficiāli iepazīstināja Rojs Fīldings savā doktora disertācijā 2000. gadā. Tas ir arhitektūras komponentu, dizaina principu un mijiedarbības kopums, ko izmanto, lai izveidotu izplatītas sistēmas, kurās iesaistīti jebkāda veida nesēji (teksts, video utt.). REST pamatā ir sistēmu veidošanas stils, kas ļauj elastīgi sazināties un parādīt informāciju tīmeklī, vienlaikus nodrošinot struktūru, kas nepieciešama, lai viegli izveidotu vispārējas nozīmes komponentus.
REST API a resurss varētu būt gandrīz jebkas, taču piemēri ietver lietotāju, tvītu sarakstu un pašreizējos tvītu meklēšanas rezultātus. Katrs no šiem resursiem ir adresējams adresē a resursa identifikators, kas tīmekļa REST API gadījumā parasti ir URL, piemēram, //api.twitter.com/1.1/users/show?screen_name=twitterdev. Kad lietojumprogramma pieprasa resursu, izmantojot identifikatoru, API piegādā pašreizējo pārstāvība šī resursa lietojumprogrammai formātā, ko lietojumprogramma var patērēt, piemēram, JPEG attēls, HTML lapa vai JSON.
Viens no lielākajiem REST atšķirīgajiem ir tas, ka tas ietver datu nosūtīšanu pieprasītājai lietojumprogrammai. Lai gan tas nodrošina lielu elastību, ļaujot lietojumprogrammai ar datiem darīt visu, ko vēlas, tas nāk par efektivitātes cenu. Datu nosūtīšana pa tīmekli apstrādei ir diezgan lēna, salīdzinot ar datu apstrādes veikšanu, kur atrodas dati, un pēc tam rezultātu nosūtīšanu.
Protams, “efektīvās” pieejas problēma ir tāda, ka sistēmām, kurās tiek izvietoti dati, pirms laika būtu jāzina, kādas lietojumprogrammas vēlas ar tām darīt. Tādējādi, lai izveidotu API, kurai ir vispārējas nozīmes lietojamība un elastība, ceļš ir REST.
API piemēri
Tur ir daudz publisku API, ar kuriem jūs varat mijiedarboties, daudzi no tiem ir no nozares behemotiem. Spēja programmatiski piekļūt kāda platformas uzņēmuma kodam, izmantojot API, būtībā padara tos par platformu. Daži pamanāmi API piemēri:
- Google API, kas ļauj jums savienot kodu ar visu Google pakalpojumu klāstu, sākot no Maps līdz Tulkotājs. API ir tik nozīmīgi Google, ka viņi iegādājās vadošo API pārvaldības platformu Apigee.
- Facebook API, kas ļauj programmatiski piekļūt Facebook sociālajam grafikam un mārketinga rīkiem. (Uzņēmums ir ierobežojis tikai tos lietotāja datus, kuriem varat piekļūt, izmantojot šīs API, no Cambridge Analytica un citiem skandāliem.)
Lai patiešām saprastu, kā darbojas API, iedziļināsimies divos veidos: Java API, kuru Java izstrādātāji izmanto, lai mijiedarbotos ar Java platformu, un Twitter API, publiska API, kuru izmantotu, lai mijiedarbotos ar sociālo tīklu. tīkla pakalpojums.
Java API
Java API ir programmatūras komponentu bibliotēka, kas pieejama “ārpus kastes” ikvienam, kurš ir instalējis Java izstrādes komplektu. Šie komponenti īsteno kopīgus uzdevumus un parasti palielina produktivitāti, jo programmētājiem katru reizi nav jāsāk no nulles. Viens no programmatūrā izmantotajiem pamatkomponentiem ir kaut kas tāds, ko sauc par sarakstu, kas, kā jūs varētu sagaidīt, seko vienumu sarakstam. Java API nosaka kas jūs varat darīt ar sarakstu: pievienot objektus, kārtot sarakstu, noteikt, vai elements ir sarakstā utt. Tas arī norāda kā veikt šīs darbības. Lai kārtotu sarakstu, jums jānorāda, kā vēlaties kārtot sarakstu: alfabētiskā secībā, skaitliskā dilstošā secībā, no spilgtākajām līdz blāvākajām krāsām utt.
Twitter API
Twitter API ir tīmekļa JSON API, kas ļauj izstrādātājiem programmatiski mijiedarboties ar Twitter datiem. Atšķirībā no Java API, kas ir iekļauts Java izstrādes komplektā, Twitter API ir tīmekļa API. Tam jābūt pieejamam, izmantojot internetu pieprasījumus pakalpojumiem, kurus mitina Twitter.
Izmantojot tīmekļa API, piemēram, Twitter, jūsu lietojumprogramma nosūta HTTP pieprasījumu tāpat kā tīmekļa pārlūks. Bet tā vietā, lai atbilde tiktu piegādāta kā vietne, cilvēka izpratnē tā tiek atgriezta formātā, kuru lietojumprogrammas var viegli parsēt. Šim nolūkam pastāv dažādi formāti, un Twitter izmanto populāru un viegli lietojamu formātu ar nosaukumu JSON. (Ja neesat pazīstams ar JSON, varat pavadīt dažas minūtes, lasot to šeit.)
Viens no čivināt pamatelementiem ir tvīts. Twitter API jums to pasaka kas jūs varat darīt ar tvītiem: meklēt tvītus, izveidot čivināt, iecienīt čivināt. Tas arī tev saka kā veikt šīs darbības. Lai meklētu tvītus, jānorāda meklēšanas kritēriji: meklētie vārdi vai atsauces, ģeogrāfiskā atrašanās vieta, valoda utt.
API dizains
API dizains ir process, kurā tiek formulēts API “kas” un “kā”. Tāpat kā jebkuram citam, ko var izveidot, arī API projektēšanā tiek izmantoti dažādi domāšanas un aprūpes līmeņi, kā rezultātā mainās atšķirīgs API kvalitātes līmenis. Labi izstrādātiem API ir konsekventa izturēšanās, tiek ņemts vērā to konteksts un tiek ņemtas vērā lietotāju vajadzības.
Konsekventa rīcība API ietvaros lielā mērā ietekmē ātrumu, kādā to var iemācīties, un iespēju, ka programmētāji pieļaus kļūdas, to lietojot. Parasti API, kas veic līdzīgas darbības, vajadzētu izturēties līdzīgi, neatkarīgi no to tehniskajām atšķirībām. Lai iegūtu nekonsekventa API piemēru, apskatīsim divus veidus, kā pievienot vienumu Java sarakstam:
Pat ja abas metodes, kā vienumus pievienot sarakstam, dara to pašu, to atgriešanas veidi (būla un tukšums) ir atšķirīgi. Izstrādātājiem, kuri izmanto šo API, tagad ir jāseko, kura metode atgriež kādu tipu, padarot API grūtāk apgūstamu un tās lietošanu vairāk pakļautu kļūdām. Tas arī nozīmē, ka kods, kas izmanto šīs metodes, kļūst mazāk elastīgs, jo tas ir jāmaina, ja vēlaties mainīt elementu pievienošanas veidu.
Konteksta ņemšana vērā ir vēl viena konsekvences forma, lai gan tas ir saistīts ar faktoriem, kas nav API. Lielisks piemērs tam, kas nav programmatūra, ir tas, kā ceļa noteikums - labās vai kreisās puses - ietekmē automašīnu dizainu dažādās valstīs. Automašīnu dizaineri ņem vērā šo vides faktoru, atrodot vadītāja sēdekli automašīnas labajā vai kreisajā pusē.
