Selles postituses püüdsin koguda teavet, mis võib olla kasulik testijatele, kes tahavad teada, mis on API. Loodan, et ka selles valdkonnas kogenud inimesed leiavad midagi kasulikku. API testimine Inimesed. Noh, või vähemalt aidake mul artiklist vigu leida :)
Mis on API

API (Application Programming Interface) on valmis klasside, protseduuride, funktsioonide, struktuuride ja konstantide kogum, mida pakub rakendus (teegi, teenus) välises kasutamiseks. tarkvaratooted(Wikipedia).

Teisisõnu annab API meile võimaluse kasutada teiste inimeste tööd oma eesmärkidel. Esimest korda puutusin API-ga kokku Windowsi näide API. See on funktsioonide kogum, mida saavad kasutada kõik antud OS-is töötavad rakendused. Näiteks võib see kasutada standardfunktsioonid liidese renderdamiseks.

Kaasaegsed API-d on sageli veebiteenuste kujul, mis pakuvad kasutajatele (nii inimestele kui ka teistele veebiteenustele) teavet. Tavaliselt on teabevahetusprotseduur ja andmeedastusvorming üles ehitatud nii, et mõlemad pooled teavad, kuidas üksteisega suhelda.

Veebisaidilt https://dev.hh.ru/ (täpsemalt https://github.com/hhru/api/blob/master/docs/general.md) leiate kirjelduse, kuidas HeadHunter API kliendid ja teenused suhtlevad omavahel. Näiteks tsitaat saidilt:

• Kõik API-d töötavad HTTPS-protokolli kaudu.
• Autoriseerimine toimub OAuth2 protokolli abil.
• Kõik andmed on saadaval ainult JSON-vormingus.
• Baas-URL - https://api.hh.ru/
• Kuupäevad on vormindatud vastavalt standardile ISO 8601: YYYY-MM-DDThh:mm:ss±hhmm

Saate lugeda HH API-d - see on hea näide kasutaja dokumentatsioon.

Andmeedastusvormingud

Kasutajate API-dega suhtlemiseks on palju andmevorminguid. Näiteks tuntud XML. Või JSON – kerge ja lihtne vorming, mis näeb välja järgmine:

( "id": "0001", "tüüp": "sõõrik", "nimi": "kook", "pilt": ( "url": "images/0001.jpg", "laius": 200, "kõrgus" ": 200 ) ) P oh ss Allpool näete vastuseid, mis pärinevad MediaWikiAPI , erinevates vormingutes :

JSON:https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=jsonfm
XML: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=xmlfm
PHP: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=php ( hoolikalt, juhtub kiikumisega fail)

HTTP g lagolid

Tavaliselt n Veebi API-le juurdepääsulkasutades Kõik HTTP-päringud on olemas . SellepärastPean sellest vähemalt lühidalt rääkima standardmeetodid, mis võivad sisalduda HTTP taotlus . Need meetodid nimetatakse ka HTTP-verbideks :

• SAADA. Tõenäoliselt kõige populaarsem tüüp nõuda. Kasutatakse andmete vastuvõtmiseks või lugemiseks.
• PANGE. Kohandatud n umbes ja spo Kasutatakse ressursi värskendamiseks .
• POSTITA. Tavaliselt kasutatakse uue ressursi loomiseks.
• KUSTUTA. Kustutab andmed.
• Ja teised

Kui tahame saada teavet ressursi kohta,mille URI http://www.example.com/kliendid/12345 , saame saata päringu:
HANKIGE http://www.example.com/customers/12345

Kui tahame ressurssi värskendada - saame saata PUT-päringu:
PUT http://www.example.com/customers/12345/orders/98765

Regulaarne HANGI taotlusi võimeline saatma veebibrauserit. Muud tüüpi päringud võivad nõuda skriptikeeli või spetsiaalsed tööriistad(sellest lähemalt allpool).

HTTP kohta meetodeid saab täpsemalt lugeda juures kohta W iki.

HTTP vastuste oodidele

Server saab saata erinevad koodid vastuseks kasutaja taotlustele. Need võivad olla veakoodid või lihtsalt koodid, mis teavitavad kasutajaid serveri olekust. Üksikasjalik kirjeldus leiab jällegi wikist.

Tuntumad koodid on 4xx (kliendipoolsed probleemid) ja 5xx (serveripoolsed probleemid). API arendajate endi otsustada, millised koodid antud olukorras tagastada. Näiteks Odnoklassniki veebisaidi API tagastab koode, mille kirjelduse leiate lehelt https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003.

Lisaks soovitan teil kuulata lugu Request Response - see on lihtne ja selge koodide kohta, mis tagastatakse HTTP päringud(ole ettevaatlik, väikemees :)).

REST API

REST API on postituse ideoloogia sülemlemine API, mis tähistabEsinduslik riigiülekanne API. See põhineb järgmistel selle looja sõnastatud põhimõtetel , Roy Fielding:

1. Klient-server arhitektuur
2. Kodakondsuseta server
3. Vahemällu mahutavus
4. Mitmekihiline struktuur
5. Ühtne liides
6. Kood nõudmisel

Ma ei lasku üksikasjadesse, kuid võin soovitada neid, kes soovivad sellel teemal lugeda

Sul on koer. Aga ta ei räägi inimkeel. Kuid ta suudab teda "mõista" käskude kaudu, mida talle koolitusprotsessi ajal õpetati. Kui ütled koerale, kes tunneb meeskonda"sussid!" midagi sellist nagu "Rexik, palun too mulle mu sussid väikeste jänkudega", ta ilmselt kuulab nime, kuid ei too susse. Seega on API käskude kogum, mille abil teie koer teid mõistab ja teeb seda, mida teie vajate. See on teekannu jaoks väga lihtsustatud, kuid olemus on minu arvates selge.

API on keel, reguleeritud viis ühe arvutiprogrammi jaoks teisega suhtlemiseks mõne programmi ühiseks täitmiseks ühine ülesanne kui üks programm täidab teise päringuid. Application Programming Interface (API) – rakenduste programmeerimisliides.

See on primitiivne analoogia juhuslikult sündinud mannekeenide kohta.

Kujutage ette 5 välismaalast, kes räägivad... erinevaid keeli kes peavad koos töötama ja elama, ütleme Venemaal. Kumbki ei oska teise keelt, kuid neil on vaja ühtse meeskonnana mõnda ülesannet täita, rollides näiteks üksteist toita ja toidu maitse üle arutleda vene keeles. Selleks tuleb söömise ajal osta toidukraami, süüa teha, laud katta ja nõusid arutada. Et nad mõistaksid üksteist ja leiaksid sealt tooteid välismaailma, treenime neid põhikomplekt venekeelsed sõnad. Kujutame ette, mis meil on:

1. Prantslane

2. Hispaanlane

4. Inglane

5. Itaalia keel

Jaotame rollid nende vahel alamülesannete täitmiseks järgmiselt:

Toidu ostmine: prantsuse ja hispaania keel

Toiduvalmistamine: hispaania, saksa ja inglise keel

Tabeliseade: inglise ja itaalia keel

Söök ja maitsete arutelu Toidud: KÕIK

Et nad saaksid kõiki neid ülesandeid täita, õpetame kõigile neid venekeelseid sõnu, mis võimaldavad neil üksteisega koostööd teha ja väliskeskkond täitke kõik need ülesanded. Vaata allolevat pilti.

Nii et siin see on. Meie välismaiste sõprade seltskond on grupp arvutiprogrammid kes peavad suhtlema omavahel ja väliskeskkonnaga.

Keel ja sõnad, mis tähistavad tooteid ja põhitoiminguid mida on vaja toota see on API– standardid, mille järgi meie välismaised sõbrad omavahel vene keeles suhtlevad, et täita kõik määratud alamülesanded.

API 1: sõnad toodete ja ostmise kohta
API 2: sõnad roogade ja toiduvalmistamisviiside jaoks
API 3: Sõnad, mis tähistavad seadmeid ja nendega seotud toiminguid
API 4: sõnad, mis tähistavad toidu maitset ja hindamist

See võib olla keerulisem, näiteks API 2 olgu türgi keel, API 3 on hiina keel, API 4 on hindi keel

Näide mannekeenide jaoks:

1. Seal on väljalaskeava. Selle taga peitub tohutu hulk tehnoloogiat. Kuid selle kasutamiseks peab teil olema pistik, mille varraste vahe on 3 cm ja pistikupesa toidab 220 V. See on tohutu elektritootmissüsteemi API liides.

2. Kas triikraud on olemas? Tal on oma keeruline süsteem tööd. Kuid pistikupesaga töötamiseks vastab see API nõuetele - vajate pistikut, mille vahemaa on 3 cm ja vastuseks on oodata 220 volti.

See on kõik. Need 2 süsteemi on sõltumatud, need on suured ja keerulised. Kuid API on loodud selleks, et üksteisega ühenduse loomine oleks võimalikult lihtne.

API – rakenduste programmeerimisliides. See on teatud funktsioonide, konstantide, klasside ja võib-olla ka muude objektide komplekt teatud programmiosaga suhtlemiseks.

Arvan, et kõige selgem viis on kirjeldada seda näitega. Oletame, et keegi kirjutas kalkulaatori, mida soovite oma programmis kasutada. Sellele kalkulaatorile tuleb kuidagi ligi pääseda. Neid kalkulaatoriga suhtlemise viise nimetatakse API-ks. Need võivad olla erinevad ja ilma nende kirjelduseta ei saa midagi teha. Võib-olla on teil funktsioon numbri mällu kirjutamiseks, toimingu sooritamiseks ja tulemuse saamiseks. Või äkki on teil üks funktsioon, mis edastab kaks numbrit ja nende vahel toimingukoodi ning tagastab kohe vastuse.

Sellised kirjeldused on tehtud kõige jaoks. Operatsioonisüsteemil on API, see on funktsioonide komplekt, millega programm luuakse: installi võrguühendus, joonista aken, töötle nupuklõpsu. Keegi API server see on funktsioonide kogum, mida see täidab. Brauser pääseb juurde Wikipedia saidile – see kasutab teie päringule vastuse tagastamiseks API-d.

API-dega töötamine võib olla nii rahuldust pakkuv kui ka masendav. Ühest küljest saate teiste rakendustega suheldes oluliselt suurendada oma rakenduse vaatajaskonna ulatust ja "vau" efekti. Teisest küljest hõlmab see hulga dokumentide lugemist, autentimisstrateegiate uurimist ja mitteinformatiivsete (või isegi puuduvate) veateadete sõelumist.

Esiteks, kui te ikka veel täielikult aru ei saa, mis on API (Application Programming Interface), lugege järele saamiseks Skillcrushi selgitust ja seejärel selle artikli esimest osa.

"API" on uskumatult lai mõiste – iga kord, kui teie rakendus "vestleb" teise rakendusega, teeb see seda mingi API kaudu. Teie enda rakenduse sees olevad komponendid, nt erinevad osad Rööpad suhtlevad omavahel ka API-de kaudu. Need on enam-vähem iseseisvad alamrakendused, mis pakuvad andmeid, mida igaüks neist vajab oma konkreetsete ülesannete täitmiseks. Rakenduste maailmas on kõik API!

Kui loote dünaamilisema esiotsa funktsionaalsusega rakendusi (nii ühelehelised Javascripti rakendused kui ka lihtsad rakendused eraldi AJAX-kõnedega), suhtlevad nad teie kaudu Railsi taustaprogrammiga enda API, mis on tegelikult vaid lisarida või kaks koodi, mis ütleb teie kontrolleritele, kuidas HTML-i asemel JSON-i või XML-i esitada.

Sellest õpetusest saate teada, kuidas luua oma API. Järgmistes õppetundides käsitleme seda, kuidas suhelda teiste rakenduste API-dega. Tunnid peaksid olema hea hüppelaud selle teema õppimiseks, kuid tõenäoliselt ei hõlma need täielikult kõiki juhtumeid. Suur osa API-dega töötamisel on teadmine, kuidas lugeda nende dokumentatsiooni ja aru saada, mida nad teilt tahavad.

Punktid, mida kaaluda

Vaadake küsimused üle ja vaadake, kas teate vastuseid. Pärast ülesande täitmist pange end uuesti proovile.

• Kuidas Rails mõistab, millist tüüpi faili te HTTP-päringu saatmisel vastuseks ootate.
• Mis on meetodi #respond_to eesmärk?
• Kuidas tagastada kasutajaobjekt, määrates samal ajal atribuudid, mida te ei soovi sellesse objekti lisada (see tähendab, et te ei saa lihtsalt tagastada User.first)?
• Nimetage kaks sammu #to_json meetodi kulisside taga.
• Kuidas öelda kontrolleri toimingule, et see kuvaks ainult veateate?
• Kuidas luua oma veateadet?
• Miks ei saa te kasutada seansipõhiseid kontrolleri autentimismeetodeid, kui soovite lubada programmilisi ühendusi oma API-ga?
• Mis on "teenustele orienteeritud arhitektuur"?

API põhitõed

Teie Railsi rakendus on tegelikult juba API, kuigi te ei pruugi seda API-na mõelda. Veebibrauser, mille teie kasutajad käivitavad, on samuti programm, nii et see teeb tegelikult teie Rails rakendusele API päringu, kui kasutaja avab uus leht. Kunagi mõtlesime nii, sest HTML-i mallide renderdamine on nii tavaline ülesanne, et me lihtsalt lisame selle funktsiooni oma serveriprogrammid nagu standardtüüp vastus ja kõike muud peame millekski ebatavaliseks.

Tihti aga soovitakse esitada taotlus, mis ei nõua kõiki brauseri kasutamisega kaasnevaid peavalusid. Te ei pruugi lehe struktuurist (HTML) hoolida, kuid vastutasuks soovite puhtaid andmeid. Oletame, et soovite saada kõigi kasutajate loendit. Saate taotleda midagi sellist nagu http://yourapplication.com/users , mis käivitab kindlasti toimingu #index ja renderdab kõigi rakenduse kasutajate loendi.

Aga milleks selle kõigega vaeva näha tarbetut teavet, kui soovite ainult kasutajate loendit hankida? Kõige rohkem lihtne variant saadab päringu samale URL-ile, täpsustades, et vastutasuks oodatakse JSON- või XML-vastust. Kui konfigureerite oma Rails-kontrolleri õigesti, saate tagasi lihtsa JSON-massiivi objekti, mis sisaldab kõiki kasutajaid. Imeline!

Sama põhimõte kehtib ka välise API-ga suhtlemisel. Oletame, et soovite saada Twitterist kasutaja hiljutisi säutse. Kõik, mida pead tegema, on öelda oma Rails-rakendusele, kuidas suhelda Twitteri API-ga (st end autentida), saata päring ja töödelda tagastatavate "säutsude" komplekti.

API loomine

Võib-olla soovite muuta oma Rails-rakenduse kasutajaliidese veebilehtede jaoks puhta taustarakendus-API või soovite lihtsalt õppida, kuidas saata JSON-i, kui kasutajaliides seda nõuab. See jaotis ei käsitle seda, kuidas luua autentimisfunktsioonidega täisväärtuslikke RESTful API-sid. See on sujuv sissejuhatus teie rakenduse käsitlemisse API-na.

Põhitõed

Kui soovite, et teie Rails-rakendus tagastaks HTML-i asemel JSON-i, peate oma kontrolleril seda tegema. Suurepärane on see, et sama kontrolleri toiming võib naasta erinevat tüüpi olenevalt sellest, kas teie kasutaja teeb tavapärase päringu brauserist või pääseb API-le juurde käsurea kaudu. See määrab taotletud faili laienduse alusel, mis tüüpi päring tehti, nt example.xml või example.json.

Saate kontrollida, mida Rails arvab soovitud failitüübist, kontrollides serveri logi:

Alustati 127.0.0.1 jaoks 127.0.0.1 jaoks mõeldud "/posts/new" hankimist 2013-12-02 15:21:08 -0800 Töötlemine PostsControlleri poolt#uus HTML-ina

Esimene rida ütleb teile, millist URL-i taotleti, ja teisel real, kuhu see saadeti ja kuidas Rails seda töötleb. Kui kasutaksite laiendit .json, näeks see välja järgmine:

Alustati "/posts.json" hankimist 127.0.0.1 jaoks 2013-12-04 12:02:01 -0800 PostsController#indexi töötlemine JSON-ina

Kui teil on jooksmine testrakendus, proovige taotleda erinevaid URL-e. Kui teie kontroller ei saa nendega hakkama, võite saada veateate, kuid peaksite siiski nägema, mida Rails teie taotlustest mõistab.

JSON-i või XML-i renderdamine

Kui otsustate, et soovite päringutele vastata kasutades JSON-i või XML-i, peate oma kontrolleril käskima HTML-i asemel JSON- või XML-i renderdamist. Üks võimalus selleks on kasutada meetodit #respond_to:

Class UsersController< ApplicationController def index @users = User.all respond_to do |format| format.html # index.html.erb format.xml { render xml: @users } format.json { render json: @users } end end end

IN antud juhul, #respond_to edastab plokile vorminguobjekti, millele saab lisada vastava renderduskutse. Kui te midagi ei tee, renderdatakse html standardse Railsi malli abil (selles näites app/views/index.html.erb).

Funktsioon #render on piisavalt nutikas, et mõista, kuidas renderdada mitmesuguseid vorminguid. Kui annate sellele võtme:json, kutsub see sisse oleva väärtuse juures välja #to_json selles näites@kasutajatele. See teisendab teie Ruby objekti(d) JSON-stringideks, mis edastatakse taotlevale rakendusele.

Nii saate oma API. Muidugi võib API loomine olla pisut keerulisem, kui soovite teha mõnda uhket asja, kuid see kõik jääb põhitõdede juurde.

Tagastatud atribuutide määramine

Oletame, et soovite veenduda, et te ei tagasta kasutaja e-posti aadressi koos objektiga Kasutaja. Sel juhul soovite muuta tagastatavaid atribuute, muutes meetodi #to_json tegevust.

Varem oleksite oma versiooniga lihtsalt alistanud meetodi #to_json, kuid nüüd pole teil seda vaja – tegelikult alistate selle asemel meetodi #as_json. Meetodit #as_json kasutatakse meetodis #to_json, nii et selle muutmine muudab kaudselt #to_json tulemust, kuid üsna spetsiifilisel viisil.

#to_json teeb 2 asja: see käivitab #as_json ja hangib JSON-i renderdatavate atribuutide räsi. Seejärel renderdatakse see JSON-iks, kasutades ActiveSupport::json.encode . Nii et #as_json muutmisega täpsustate meetodi #to_json seda osa, mida soovite tegelikult muuta.

Meie puhul teeme seda, muutes oma mudelis #as_json, et tagastada ainult meile vajalikud atribuudid:

# app/models/user.rb klassi kasutaja< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # ÄRGE lisage meili lõpuvälja # Valik 2: Kasutage standardmeetod#as_json def as_json(options=()) super(ainult: [:name]) end end

Seejärel peab meie kontroller lihtsalt renderdama JSON-i nagu tavaliselt (allolevas näites tagastatakse JSON alati, olenemata sellest, kas HTML-i päring saadeti või mitte):

# app/controllers/users_controller.rb klass UsersController< ApplicationController def index render json: User.all end end

Pange tähele, et #render kasutamisel ei pea te ise numbrit #to_json kutsuma – see teeb seda teie eest.

Mõnikord võib Heroku nõuda täiendavad sammud vigadega lehtede korrektseks kuvamiseks. Viska pilk peale. Võimalik, et peate esmalt eemaldama rakendusest/avalikust kataloogist staatilised lehed.

Turvalisuse tagamine väljastpoolt

Oletame, et soovite lubada juurdepääsu API-le ainult siis, kui kasutaja on sisse logitud. Teie kontrolleris olev autentimine juba teeb seda tööd – lihtsalt veenduge, et teil oleks õige komplekt #before_action (nt before_action:require_login). Teil võib vaja minna funktsioone, kus lehte saavad vaadata nii sisseloginud kui ka sisselogimata kasutajad, kuid igaüks peaks nägema erinevaid andmeid. Te ei soovi, et autentimata kasutajad saaksid tundlike andmete hankimiseks API-kõnesid teha. Samuti ei soovi te lubada volitamata kasutajatel külastada teatud HTML-lehti.

Kui soovite käsitleda taotlusi rakendusest, mis ei ole brauser (nt käsurida), ei saa te autentimisel tugineda brauseri küpsistele. Seetõttu kasutab enamik API-sid autentimisprotsessi osana natiivseid märke. Räägime žetoonidest veidi lähemalt järgmises õppetükis.

Järgmised sammud

Nüüd on teil oskused kasutada oma Rails-rakendust mitte ainult HTML-i, vaid ka mis tahes muu vormingu renderdamiseks. Kui soovite minna kaugemale ja lubada teistel arendajatel teie platvormi kasutades asju luua (näiteks selleks, et nad saaksid kasutajana autentimise asemel teha programmilisi päringuid), peate muutma oma API süsteemi palju tugevamaks. Me ei käsitle seda kõike siin, kuid vaadake järgmist:

• Artiklis Awesome Rails API-de loomine kirjeldatakse paljusid parimaid lähenemisviise mänguasjarakenduselt tööstuslike API standardite poole liikumiseks.

Teenusele orienteeritud arhitektuur

On aeg tutvustada arhitektuurne lähenemine SOA (Service-Oriented Architecture) nime all. Põhiidee on see, et teie rakendus koosneb paljudest teenustest, nagu maksesüsteem, kasutaja registreerimine, soovituste moodul jne. Selle asemel, et ehitada see kõik ühte põhirakendusse, jagate alamsüsteemid täiesti sõltumatuteks tükkideks, mis suhtlevad üksteisega sisemiste API-de abil.

See on hea mitmel põhjusel. Kuna iga teie rakenduse osa ei hooli sellest, kuidas teised osad töötavad ja teab vaid, kuidas oma API kaudu andmeid küsida, saate teenusekoodi oluliselt muuta ja ülejäänud rakendus töötab nagu varem. Saate ühe teenuse täielikult asendada teisega ja seni, kuni see suhtleb samade API meetodite abil, läheb see väga sujuvalt. Oma rakenduse kirjutamise asemel saate kasutada väliseid API-sid (nt maksesüsteeme). Saate luua PHP-rakenduse, mis suhtleb Pythoni rakendusega, mis suhtleb Rails-rakendusega, ja kõik toimib, kuna nad suhtlevad üksteisega API abil.

Üldreeglina proovige muuta oma taotluse iga osa võimalikult sõltumatuks - hea mõte. SOA kontseptsioon sunnib teid mõtlema sellele, milliseid meetodeid soovite oma rakenduse muudele osadele avaldada, mis muudab ka teie koodi paremaks. Lisaks, kui eeldate, et teie rakenduse iga põhikomponent on sõltumatu, saate ka probleeme palju hõlpsamini eraldada ja vigu sisukamalt käsitleda.

Teeninduskeskse arhitektuuri kasutamine terve rakenduse jaoks on nagu hiiglasliku keeruka Ruby skripti jagamine puhasteks klassideks ja meetoditeks, ainult suuremas skaalas.

Üks tuntumaid teenusele orienteeritud arhitektuurile ülemineku juhtumeid on Amazon.com. Ühel päeval 2002. aastal ütles Jeff Bezos otsekoheselt, et kõik töörühmad peavad kolima SOA-sse või tuleb vallandada. Kurikuulus ajaveebi postitus Google'i töötaja, mis oli mõeldud sisemiseks, kuid kogemata avalikuks tehtud, rääkis Amazoni võimsusest SOA-d kasutades. See on suurepärane lugemine, nii et vaadake seda kindlasti, kuid Bezose kirja põhipunktid on kokku võetud järgmistes postituse tsitaatides:

1) Kõik meeskonnad pakuvad nüüd oma andmeid ja funktsioone teenindusliideste kaudu.

2) Nende liideste kaudu peavad meeskonnad omavahel suhtlema.

3) Muud vormid protsessidevaheline suhtlus keelatud: otsesed lingid puuduvad, teise käsu andmete otsene lugemine, mudelid puuduvad jagatud mälu, ei mingeid tagauksi vms. Ainus lubatud suhtlusviis on juurdepääsu teenuseliidesele võrgu kaudu.

4) Pole vahet, millist tehnoloogiat nad kasutavad. HTTP, Corba, Pubsub, patenteeritud protokollid – vahet pole. Bezos ei hooli.

5) Kõik teenindusliidesed, eranditult, peavad olema algselt kavandatud väliselt juhitava võimalusega. See tähendab, et meeskond peab kavandama ja kavandama, et oleks võimalik pakkuda liidest väljaspool ettevõtet arendajatele. Ei mingeid erandeid.

6) Kõik, kes neid nõudeid eirab, vallandatakse.

SOA on tõsine äri. Muidugi, selle kasutamisel tekib palju probleeme – vaadake seda postitust Amazoni "õpetuste" kohta -, kuid sellel on uskumatult palju eeliseid.

Tõenäoliselt ei muretse te SOA pärast liiga palju, kui loote endale mänguasjarakendusi, kuid see on kindlasti probleem, mis kerkib esile IT-ettevõttesse tööle asudes, seega on sellega tutvumine hea tava.

Sinu eesmärk

1. JSON-i ja XML-i renderdamise õppimiseks lugege Rails Controllers Guide'i jaotist 7.
2. Neid pole vaja vaadata (kuna need ulatuvad veidi kaugemale, kui me praegu valmis oleme), kuid kui olete huvitatud, vaadake Railscastsi jaotises Täiendavad ressursidõppetunni lõpus, et saada lisateavet API eeliste kohta.

Järeldus

Javascripti kursuse ajal teeme teie rakendusega API-na tihedamat koostööd. Sellel kursusel saate luua mitu täispinu rakendust, mis kasutavad AJAX-i kõnesid paremaks kasutajaliides, mis tegelikult hõlmab XML-i renderdamist või JSON-i andmed täieliku HTML-lehe asemel. Seejärel loote mitu ühelehelist Javascripti rakendust, mis tuginevad teie Railsi rakenduse pakutavale API-le, et tuua kõik vajalikud andmed andmebaasist, kuid muul juhul töötavad need kliendi poolel (brauseris).

Parim viis API mõistmiseks on selle loomine ja sellega suhtlemine, millele me oma projektides keskendume.

Olete ilmselt näinud terminit "API". Operatsioonisüsteemi, veebibrauseri ja rakenduste värskendused annavad arendajatele sageli teada uutest API-dest. Aga mis on API?

Rakenduse programmeerimisliides

Termin API on akronüüm ja see tähistab rakenduste programmeerimisliidest.

API on nagu restorani menüü. Menüü sisaldab tellitavate roogade loendit, samuti iga roa kirjeldust. Kui määrate, milliseid menüüelemente soovite, teeb restoraniköök selle töö ära ja varustab teid valmistoiduga. Sa ei tea täpselt, kuidas restoran seda toitu valmistab, ega ka vaja.

Samuti pakub API palju toiminguid, mida arendajad saavad kasutada, ja ka nende tegemiste kirjeldust. Arendaja ei pea teadma, kuidas näiteks luuakse operatsioonisüsteem ja kuvatakse dialoogiaken Save As. Nad peavad lihtsalt teadma, et see on rakenduses kasutamiseks saadaval.

See ei ole täiuslik metafoor, kuna arendajad peavad tulemuste saamiseks esitama oma API-andmed, nii et võib-olla on see rohkem nagu väljamõeldud restoran, kus saate köögi jaoks oma koostisosi pakkuda.

API-d võimaldavad arendajatel säästa aega, kasutades platvormi rakendamise eeliseid oluline töö. See aitab vähendada arendatava koodi hulka ja samuti luua järjepidevust samal platvormil olevate rakenduste vahel. API-d saavad kontrollida juurdepääsu riist- ja tarkvararessurssidele.

API-d muudavad arendajate elu lihtsamaks

Oletame, et soovite arendada iPhone'i rakendust. operatsioonisüsteemi Apple iOS annab suur hulk API-d on nagu iga teine ​​operatsioonisüsteem, et seda teie jaoks lihtsamaks muuta.

Näiteks kui soovite ühe või mitme veebilehe kuvamiseks manustada veebibrauseri, ei pea te oma veebibrauserit nullist oma rakenduse jaoks programmeerima. Sina
WebKiti (Safari) veebibrauseri manustamiseks oma rakendusse saate kasutada WKWebView API-d.

Kui soovite pildistada või videoid teha iPhone'i kaamerad Te ei pea ise kaameraliidest kirjutama. Saate kasutada kaamera API-d iPhone'i kaamera manustamiseks oma rakendusse. Kui API-d poleks olemas, peaksid rakenduste arendajad looma oma kaameratarkvara ja tõlgendama sisendeid riistvara kaamerad. Aga operatsioonisaali arendajad Apple süsteemid on teinud kogu selle raske töö, et arendajad saaksid kaamera manustamiseks kasutada lihtsalt kaamera API-d ja seejärel jätkata oma rakenduse kirjutamist. Ja kui Apple täiustab kaamera API-d, kasutavad kõik seda kasutavad rakendused seda täiustust automaatselt ära.

See kehtib kõigi platvormide kohta. Näiteks kas soovite luua Windowsis dialoogiboksi? Selle jaoks on olemas API. Kas soovite Androidis sõrmejäljega autentimist toetada? Selle jaoks on API, nii et te ei pea testima iga Androidi tootja iga sõrmejäljeandurit. Arendajad ei pea jalgratast ikka ja jälle leiutama.

API-d kontrollivad juurdepääsu ressurssidele

API-sid kasutatakse ka riistvaraseadmetele ja funktsioonidele juurdepääsu kontrollimiseks tarkvara, mille kasutamiseks rakendusel ei pruugi olla luba. Seetõttu mängivad API-d turvalisuses sageli suurt rolli.

Näiteks kui olete kunagi külastanud veebisaiti ja näinud oma brauseris teadet, et veebisait küsib teie täpset asukohta, proovib see veebisait teie veebibrauseris kasutada geograafilise asukoha API-t. Veebibrauserid pakuvad API-sid, et hõlbustada veebiarendajatel teie asukohale juurdepääsu – nad saavad lihtsalt küsida "kus te olete?" ja brauser teeb raske töö teie GPS-ile või lähedale pääsemiseks Wi-Fi võrgud oma füüsilise asukoha leidmiseks.

Kuid brauserid pakuvad seda teavet ka API-de kaudu, kuna juurdepääsu sellele saab kontrollida. Kui veebisait soovib juurdepääsu teie täpsele asukohale, ainus viis saada see läbi Asukoha API. Ja kui veebisait proovib seda kasutada, saate teie – kasutaja – taotluse lubada või tagasi lükata. Juurdepääs riistvararessurssidele nagu GPS andur, on võimalik ainult API kaudu, nii et brauser saab kontrollida juurdepääsu riistvarale ja piirata rakenduste võimalusi.

Sama põhimõtet kasutatakse tänapäevaste mobiiltelefonide puhul. operatsioonisüsteemid, näiteks iOS ja Android, kus mobiilirakendused neil on õigused, mida saab jõustada API-le juurdepääsu kontrollimisega. Näiteks kui arendaja üritab kaamera API kaudu kaamerale juurde pääseda, saate loataotluse keelata ja rakendusel puudub juurdepääs teie seadme kaamerale.

Lubasid kasutavatel failisüsteemidel, nagu Windows, Mac ja Linux, on need õigused, mida jõustab API failisüsteem. Tüüpiline rakendus ei oma otsest juurdepääsu töötlemata füüsilisele kõvaketast. Selle asemel peab rakendus pääsema failidele juurde API kaudu.

API-sid kasutatakse teenustevaheliseks suhtluseks

API-sid kasutatakse ka muudel põhjustel. Näiteks kui olete kunagi näinud veebisaidile manustatud Google Mapsi objekti, kasutab see veebisait selle kaardi manustamiseks Google Mapsi API-t. Google pakub selliseid API-sid veebiarendajatele, kes saavad seejärel API-sid kogumiseks kasutada keerulised objektid otse teie veebisaidil. Kui selliseid API-sid pole, võivad arendajad ise luua enda kaardid ja esitage oma kaardi andmed, et mahutada väike interaktiivne kaart veebisaidil.

Ja kuna see on API, saab Google juurdepääsu juhtida Google Maps kolmandate osapoolte veebisaitidel, tagades, et nad kasutavad seda järjepidevalt, selle asemel, et proovida juhuslikult rakendada veebisaidil kuvatavat raami Google Maps, Näiteks.

See kehtib paljude erinevate võrguteenuste kohta. Teksti tõlke taotlemiseks on API-liidesed Google'i tõlge või kuvada Facebooki kommentaarid või Twitteri säutsud veebisaidil.

OAuthi standard määratleb ka mitmed API-d, mis võimaldavad teil saidile mõne muu teenuse kaudu sisse logida, kasutades näiteks oma sisselogimismandaate. Facebooki postitused, Google'is või Twitteris, et logida sisse ilma uut veebisaiti loomata konto kasutaja ainult sellel saidil. API-d on standardlepingud, mis määravad, kuidas arendajad teenusega suhtlevad ja millist väljundit arendajad peaksid ootama.

Kui olete seda artiklit lugenud, saate paremini aru, mis API on. Lõppkokkuvõttes ei pea te teadma, mis API on, välja arvatud juhul, kui olete arendaja. Aga kui sa seda näed tarkvaraplatvorm või teenus lisatud uued API-d erinevate riistvara või teenuste puhul peaks arendajatel olema selliseid funktsioone lihtsam kasutada.

Kolleegide töö hõlbustamiseks ja kõikidele Windowsi programmidele universaalse liidesega varustamiseks lõid Microsofti programmeerijad sellise asja nagu API – "Application Programming Interface".

See on funktsioonide ja protseduuride komplekt, mida programmid saavad kõige sagedamini kasutada: kataloogipuu kuvamine, failide otsimine, standardse akna kuvamine sulgemis-, minimeerimis- ja maksimeerimisnuppudega ja paljud teised. Tänu sellele ei pea Windowsi jaoks programmi loov arendaja läbi mõtlema ja välja töötama spetsiaalseid alamprogramme programmiakna, kausta valimise akna ja muude sarnaste elementaarsete toimingute kuvamiseks – ta peab lihtsalt helistama kernel32.dll või user32. dll teekidest, mis sisaldavad funktsioone ja protseduure API, vajalikku funktsiooni ja ta teeb kõik tema eest ise. Selliseid funktsioone ja protseduure on palju - umbes 600.

Operatsiooniruumis MS-DOS süsteem sellist asja nagu API ei olnud - see, kes võttis endale selle operatsioonisüsteemi jaoks programmi kirjutama, oli kohustatud läbi mõtlema ja rakendama meetodid pildi ekraanil kuvamiseks, kasutajalt andmete vastuvõtmiseks, failisüsteemis reisimiseks, joonistamiseks graafika, kui selline võimalus oli vajalik 2. See muutis kasutajasõbraliku liidesega programmide väljatöötamise protsessi väga töömahukaks protsessiks, mis sageli ületas programmi jaoks vastuvõetava graafilise liidese loomisele kulunud kulud programmi enda algoritmi, mille jaoks see loodi, juurutamiseks; . Pole asjata, et nn konsoolirakendused olid väga levinud, st programmid, mis töötasid ainult käsurealt, ilma liideseta - andmed sisestati samale käsureale või tehti sellel määratud failist, ja tulemused väljastati lihtsa teksti režiimis.

Operatsioonitoa tulekuga Windowsi süsteemid Programmeerijate seljatagav töö programmi välimuse ja mugavate teabe sisestamise ja väljastamise viiside väljatöötamiseks hõlbustas oluliselt - API-funktsioonid olid kasutusel juba Windows 3.0-s. Nüüd, kui programmeerija tahtis luua näiteks tekstisisestusakent või kerimisriba, pidi ta lihtsalt kirjutama sellise akna kuvamise funktsioonile, millel on vajalikud parameetrid, nagu iga teinegi keeles, milles ta oma programmi kirjutas, ja mitte kasutusele võtta tohutul hulgal koodi, et luua programm, mis sellise akna või riba ümber joonistab (samas olles teadlik, et järgmise programmi väljatöötamisel, mis kasutab ka selliseid objekte, peab ta välja töötama sellist koodi uuesti või proovige osaliselt kasutada vana, kohandades seda selle uue programmi vajadustega). Seetõttu tegi API-de ilmumine programmeerimistehnoloogias revolutsioonilise läbimurde, võimaldades luua vajalikud programmid tuttava mugava liidesega palju kiiremini, muretsemata selliste rutiinsete detailide pärast nagu standardse liidese objektide programmeerimine teabe sisestamiseks ja väljastamiseks.

IN Visuaalne keel Basic for Applications (VBA) nimetatakse paljusid API funktsioone ja protseduure iseenesteks, kui tõlk programmi käivitab, seega pole absoluutselt vajadust neid kasutada tekstisisestus- ja väljundakende kuvamiseks, ekraanile geomeetriliste kujundite joonistamiseks ja muudeks lihtsateks toiminguteks. - VBA kutsub neid vastavalt vajadusele ja sellel põhinev programm peab kasutama ainult selle keele vastavaid funktsioone. Mõnikord on aga vajadus teatud toimingute järele, mille jaoks pole sisseehitatud analooge VBA funktsioonid või nad töötavad ebaratsionaalselt või liiga aeglaselt. Näiteks kaustavaliku aken kataloogipuu kujutisega (joonis 5.1) või failiotsinguprogramm (analoogselt VBA funktsioonidele – objekt "Application.FileSearch" - töötab suure hulga failidega liiga aeglaselt). Sellistel juhtudel pakub VBA võimalust kutsuda API funktsioone.

Kahjuks pole API-funktsioonide kasutamist VBA-s spikris dokumenteeritud, nii et nende kasutamise õppimiseks tuleb otsida kontoriprogrammeerimist käsitlevaid raamatuid või veebiallikaid või analüüsida API funktsioonide väljakutseid sisaldavate programmide koodi.

Enamikul juhtudel saate Office'i jaoks programmeerimisel hakkama ka ilma API kasutamine, kuid mõnikord võib seda saavutada lihtsalt API funktsiooni kutsumisega soovitud tulemus. Oletame, et peate tagama erinevate makrode kutsumise, kui klõpsate lihtsalt hiirega paneeli nuppu. Wordi tööriistad ja kui vajutate seda nuppu ja Shift klahvid või Control. Siin on koodilõik, mis seda teeb:

Deklareerige funktsioon GetAsyncKeyState Lib "user32.dll" (ByVal kState As Long) täisarvuks

GetAsyncKeyState(vbKeyShift või vbKeyControl)

Kui GetAsyncKeyState(vbKeyShift) Siis

Kõne makro1: Välju Sub

ElseIf GetAsyncKeyState(vbKeyControl) Siis

Kõne makro2: Välju Sub

Esimene rida on nagu API funktsiooni "reserveerimine" VBA programmis kasutamiseks. Näha on, et teegist (ainult teiste programmide jaoks mõeldud programme sisaldav fail) user32.dll kutsutakse välja funktsioon GetAsyncKeyState ja sellele funktsioonile edastatakse võtmenumber ning see tagastab täisarvu (just 0, kui vastava numbriga klahvi ei vajutata ja vajutamisel -32767 või 1). Kõik funktsioonid või protseduurid, mida kutsutakse välja mitte-VBA teekidest, tuleb nii reserveerida, kasutades käsku Declare.

Käsu fraas vbKeyShift asendab Shift-klahvi koodi (selle väärtus on 16) ja vbKeyControl, nagu on lihtne mõista, asendab Control-klahvi koodi. "Kui...Siis" lausete struktuur tundub olevat selge 3, aga kui ei, siis vaadake VBA spikrit. Nagu mäletate, tähendab makro nime ees olev Call käsk selle käivitamist.

Internetis on API 4-le pühendatud venekeelseid saite. Selle funktsioonikomplekti kohta lisateabe saamiseks külastage neid.