Tento krátky termín je dobre známy každému, kto sa nejakým spôsobom stretol s vývojom. Ale nie každý rozumie tomu, čo presne to znamená a prečo je to potrebné. Vývojár Peter Gazarov hovoril o API jednoduchými slovami vo svojom blogu.
Skratka API znamená „Application Programming Interface“ (rozhranie pre programovanie aplikácií, rozhranie pre programovanie aplikácií). Väčšina veľkých spoločností v určitej fáze vyvíja API pre klientov alebo na interné použitie. Aby ste pochopili, ako a ako sa API používa vo vývoji a podnikaní, musíte najprv pochopiť, ako funguje World Wide Web.
World Wide Web a vzdialené servery
WWW si možno predstaviť ako obrovskú sieť prepojených serverov, ktoré ukladajú každú stránku. Bežný laptop sa môže zmeniť na server schopný obsluhovať celú lokalitu v sieti a vývojári používajú lokálne servery na vytváranie lokalít predtým, ako ich otvoria širokému okruhu používateľov.
Pri písaní do panela s adresou prehliadača www.facebook.com na vzdialený server Facebook sa odošle zodpovedajúca požiadavka. Keď prehliadač dostane odpoveď, interpretuje kód a vykreslí stránku.
Zakaždým, keď používateľ navštívi stránku na webe, interaguje s API vzdialeného servera. API je časť servera, ktorá prijíma požiadavky a odosiela odpovede.
API ako spôsob, ako slúžiť zákazníkom
Mnoho spoločností ponúka API ako hotový produkt. Napríklad Weather Underground predáva prístup k svojmu API údajov o počasí.
Scenár použitia: na stránke malej firmy je formulár na objednávanie stretnutí pre klientov. Spoločnosť chce do neho vložiť Google Calendar, aby zákazníci mohli automaticky vytvárať udalosť a vyplniť podrobnosti o nadchádzajúcom stretnutí.
Aplikácia API: cieľ – server lokality by mal priamo kontaktovať server Google so žiadosťou o vytvorenie udalosti so špecifikovanými podrobnosťami, prijať odpoveď od spoločnosti Google, spracovať ju a odovzdať príslušné informácie prehliadaču, napríklad správu s potvrdením používateľovi .
Alternatívne môže prehliadač zaslať požiadavku na rozhranie API servera Google a obísť server spoločnosti.
Ako sa Google Calendar API líši od API akéhokoľvek iného vzdialeného servera v sieti?
Technicky je rozdiel vo formáte požiadavky a odpovede. Na vygenerovanie kompletnej webovej stránky prehliadač očakáva odpoveď v značkovacom jazyku HTML, zatiaľ čo rozhranie Google Calendar API vráti iba údaje vo formáte ako JSON.
Ak požiadavku na API zadáva server webovej stránky spoločnosti, potom je to klient (rovnako ako klient je prehliadač, keď používateľ otvorí webovú stránku).
Vďaka API dostane používateľ možnosť vykonať akciu bez opustenia webovej stránky spoločnosti.
Väčšina moderných webových stránok používa aspoň niekoľko rozhraní API tretích strán. Mnohé úlohy už majú hotové riešenia, ktoré ponúkajú vývojári tretích strán, či už ide o knižnicu alebo službu. Často je jednoduchšie a spoľahlivejšie uchýliť sa k hotovému riešeniu.
Mnoho vývojárov distribuuje aplikáciu na niekoľko serverov, ktoré navzájom spolupracujú pomocou API. Servery, ktoré vykonávajú pomocnú funkciu vo vzťahu k hlavnému aplikačnému serveru, sa nazývajú mikroslužby.
Keď teda spoločnosť ponúka svojim používateľom rozhranie API, znamená to jednoducho, že vytvorila sériu špeciálnych adries URL, ktoré vracajú údaje iba ako odpoveď.
Takéto požiadavky možno často odosielať prostredníctvom prehliadača. Keďže prenos dát cez HTTP je v textovej forme, prehliadač vždy dokáže zobraziť odpoveď. Napríklad prostredníctvom prehliadača môžete priamo pristupovať k GitHub API (https://api.github.com/users/petrgazarov) a bez prístupového tokenu a získať nasledujúcu odpoveď vo formáte JSON:
Prehliadač perfektne zobrazuje odpoveď JSON, ktorú je možné vložiť do kódu. Stačí jednoducho extrahovať údaje z takéhoto textu, aby ste ich mohli použiť podľa vlastného uváženia.
Niekoľko ďalších príkladov API
Slovo „aplikácia“ (aplikovaná, aplikácia) môže byť použité v rôznych významoch. V kontexte API to znamená:
- softvér so špecifickou funkciou,
- server ako celok, aplikácia ako celok alebo len samostatná časť aplikácie.
Písmeno „A“ v anglickej skratke môže nahradiť akýkoľvek softvér, ktorý sa dá jasne odlíšiť od prostredia a môže mať aj nejaký druh API. Napríklad, keď vývojár implementuje do kódu knižnicu tretej strany, stane sa súčasťou celej aplikácie. Keďže ide o samostatný softvér, knižnica bude mať nejaký druh rozhrania API, ktoré jej umožní interakciu so zvyškom kódu aplikácie.
V objektovo orientovanom dizajne je kód reprezentovaný ako kolekcia objektov. V aplikácii môžu byť stovky takýchto objektov vzájomne interagujúcich. Každý z nich má svoje API – sadu verejnosti vlastnosti a metódy interakcie s inými objektmi v aplikácii. Objekty môžu mať tiež súkromné, interná logika, ktorá je skrytá pred okolím a nie je API.
Deklarovať názov funkcie Lib "libname" [()]
Kľúčové slovo Lib určuje, v ktorej knižnici môže Visual Basic nájsť požadovanú funkciu. Toto sa vzťahuje na knižnice dynamických odkazov (*.dll). Ale nemusíte špecifikovať príponu v aliasname. Alias určuje, pod akým názvom má program hľadať danú funkciu v knižnici. Arglist sú odovzdané parametre.Windows-API umožňuje dve veci: spúšťanie určitých úloh a prístup k systémovým prostriedkom. Zoznam rôznych funkcií API a ich deklarácií si môžete pozrieť pomocou štandardného programu API-Viewer.
Rozhrania API systému Windows možno volať z jazyka Visual Basic na vykonávanie úloh, na ktoré štandardný kód jazyka Visual Basic nestačí. Napríklad štandardné nástroje Visual Basic neumožňujú reštartovať počítač. Opätovné načítanie je však možné vykonať volaním príslušnej funkcie Window API.
Poznámka: Ak funkcia API od vás očakáva premennú, musíte nevyhnutne deklarujte ho a vyplňte medzerami. Tie. premenná musí byť definovaná používateľom. Toto sú vlastnosti jazyka C ++, v ktorom bolo napísané Windows API.
Pozrime sa na pár príkladov:
Povedzme, že vaša aplikácia potrebuje definovať adresár, kde je nainštalovaný operačný systém Windows 95/98/NT. Najjednoduchší spôsob, ako to urobiť, je použiť funkciu GetWindowsDirectory API.
1. V module deklarujeme funkciu GetWindowsDirectory API:
3. V hlavnom podprograme zadáme:
| Kód |
| „Premennú, ktorá sa má odovzdať do API, už máme “ vyhlásil a teraz vyplňte medzery. Mier by malo byť približne toľko ako "približne koľko znakov by mala mať premenná. „V tomto prípade stačí 20, pretože Windows je zvyčajne nainštalovaný v " C:\Windows alebo C:\Win95 atď. Teda skôr súčet znakov „Celkový počet nepresiahne 20 WindDir = Medzerník (20) Debug.Print Left(WinDir, GetWindowsDirectory(WinDir, 20)) „Keďže API je funkcia, musí nejakú vrátiť "value. V tomto prípade funkcia GetWindowsDirectory vráti "dĺžka želanej hodnoty. Teda ak je napríklad želaná hodnota " je C:\WINDOWS, potom funkcia vráti hodnotu 10. „Premenná má dĺžku 20. Týchto 10 znakov je zapísaných „najprv a potom nasleduje 10 medzier. "ďalších 10 znakov? Zaberá to zbytočnú pamäť... „Preto s inštrukciou Left vytiahneme premennú WinDir "Presne toľko prvých postáv, koľko je potrebné... |
Druhý príklad:
Váš program musí napríklad určiť, ktoré z vašich médií je CD-ROM alebo vzdialené atď. „Natívny“ balík nástrojov Visual Basic vám to neumožňuje – musíte sa uchýliť k pomoci funkcie GetDriveType API.
1. V module deklarujeme funkciu GetDriveType API:
2. V hlavnom podprograme zadajte:
Tu je to, čo nám funkcia GetDriveType vráti napríklad pre mňa:
A:-2
C: -3
D:-3
E: -5
Všetky ostatné písmená sú označené číslom 1. Áno, aby ste pochopili tieto označenia, potrebujete poznať nasledujúcu tabuľku:
Konštantný názov a hodnota:
DRIVE_UNKNOWN 0
DRIVE_NO_ROOT_DIR 1
DRIVE_REMOVEABLE 2
DRIVE_FIXED 3
DRIVE_REMOTE 4
DRIVE_CDROM 5
DRIVE_RAMDISK 6
Hlavný podprogram v module je ako Form_Load na formulári, t.j. sa považuje za hlavný a štandardne sa načítava. späť
Účel mnohých funkcií API možno ľahko uhádnuť podľa ich názvu. Napríklad GetWindowsDirectory (získajte adresár Windows) alebo GetDriveType (získajte typ média).
Odpoveď prevzatá z: www.mtsecurity.narod.ru
Vydali sme novú knihu „Marketing obsahu sociálnych médií: Ako sa dostať do hlavy predplatiteľov a prinútiť ich, aby sa zamilovali do vašej značky.“
API je externé rozhranie na programovanie aplikácie, prístup na stránky pomocou špecifického protokolu na získanie informácií a zjednodušenie vývoja programov súvisiacich s internými službami.
Čo znamená API
Najjednoduchšou analógiou pre použitie API by bol proces práce na kalkulačke pre zložité výpočty. Povedzme, že máte úlohu, viete pochopiť jej podstatu, zostaviť rovnice a grafy, ale neviete, ako robiť aritmetické operácie s číslami. Vedľa vás leží kalkulačka, ktorá tieto operácie ľahko zvládne. Neviete, čo sa deje vo vnútri počítača, a ani to vedieť nepotrebujete. Informácie poskytujete v jednej forme a prijímate ich v inej forme, ktorá je potrebná pre vaše účely.
Na tomto princípe funguje každé API. Nezáleží vám na tom, ako program dostane odpoveď, akou cestou v ňom žiadosť prechádza, ako sa robia výpočty. Máte istotu len v jednom - ako odpoveď sa vydajú štandardizované informácie o úspešnosti operácie alebo jej chybe.
Rozhranie API vám umožňuje nestrácať čas, peniaze a úsilie na nákup „nového bicykla“. Získate funkčný informačný port, ktorý prijíma a odosiela potrebné množstvá údajov na účely vášho vývoja.
výhody:
- Úspory pri vývoji vášho rozhrania.
- Nie je potrebné chápať nuansy problému.
- API sú vyvíjané profesionálmi a berú do úvahy všetky faktory interných procesov, o ktorých pri vytváraní vášho riešenia možno neviete.
- Umožňuje vám komunikovať s uzavretými službami prostredníctvom iných protokolov.
mínusy:
- V prípade aktualizácie cieľovej služby API nie vždy okamžite získa plnú funkčnosť.
- Nedokážete zachytiť chyby a neviete, ako prebieha proces v cudzom kóde.
- Rozhranie API nie vždy poskytuje časovo najoptimálnejší výsledok, pretože je navrhnuté tak, aby riešilo všeobecné prípady, nie konkrétne prípady.
Príklady API
Integrácia API je proces pripojenia aplikácie k externému dátovému rozhraniu. Práca s API začína štúdiom dokumentácie a použitých protokolov a potom priamou integráciou vášho programu do rozhrania. Zvážte najobľúbenejšie služby, ktoré majú svoje vlastné API.
VKAPI
Externé rozhranie pre interakciu populárnej sociálnej siete VKontakte s klientmi, ako aj s aplikáciami prehliadača a servera. Umožňuje vám spravovať správy komunity, obaly skupín, používateľské stránky, ak máte príslušné prístupové kľúče.
Všetky požiadavky sa posielajú na adresu https://api.vk.com/method/
Za lomkou nasleduje názov použitej metódy API a odovzdajú sa parametre požiadavky GET. Odpoveď prichádza aj cez HTTPS vo formáte JSON.
TELEGRAM BOT API
Jedno z najpopulárnejších API. S jeho pomocou sú roboty ovládané v telegramovom messengeri. Po vytvorení robota cez @botfather a získaní potrebných prístupových kľúčov môžete začať komunikovať s backendom.
Žiadosti sa podávajú na https://api.telegram.org/bot0000000:token/
Kde je bot0000000 nahradený jedinečným identifikátorom vášho bota a token vyjadruje tajný kľúč.
Požiadavky sa odosielajú prostredníctvom pripojenia HTTPS, názov metódy sa uvádza lomkou k hlavnej adrese. Odpoveď prichádza vo formáte JSON.
OTVORENÉ API POČASOVEJ MAPY
Často je potrebné získať informácie o počasí bez použitia widgetov a platených aplikácií tretích strán. Služba OpenWeatherMap prichádza na pomoc s otvoreným a bezplatným API. Po registrácii a získaní identifikačných údajov môžete zo serverových skriptov odosielať požiadavky na počasie po celom svete. V reakcii na ID mesta zdroj vráti najpodrobnejšie informácie o aktuálnom počasí a poskytne predpoveď na blízku budúcnosť.
Pracovný formát: HTTP prenos cez api.openweathermap.org/data/2.5/weather?id= s uvedením identifikačného čísla požadovaného mesta. Odpoveď servera: JSON.
Google Maps API
Čo môže byť krajšie ako interaktívna mapa sveta na stránke? Najmä ak nejde o vložku šablóny z Máp Google, ale o vaše osobné vydanie obľúbenej mapy s osobnými zhlukami značiek. Mapa bude interagovať s ostatnými skriptami na stránke a odosielať informácie o kliknutiach a súradniciach.
Google Maps JavaScript API ponúka podobné možnosti. Modul je plne naskriptovaný a funguje na strane prehliadača, takže nepotrebujeme HTTP požiadavky z PHP a vytváranie hlavičiek na strane servera, ako to bolo v prípade iných API.
Napríklad umiestnenie značky na mapu by vyzeralo takto:
var mark = new google.maps.Marker((
pozícia: myPOS,
map:map,
názov: "Ahoj!"
});
Aké je použitie API a prečo je užitočné
Existuje pomerne málo užitočných funkcií.
Prvý aspekt
Môžete vytvoriť interaktívnu interakciu používateľa so sociálnymi sieťami a instant messengermi, využiť možnosti výpočtových systémov tretích strán na zobrazenie výmenných kurzov, počasia a iných dôležitých informácií.
Pomocou API sa môžete okamžite pripojiť k serverom iných zdrojov a softvérových riešení, čo by pri typickej implementácii trvalo týždne vývoja. API zjednodušuje život tam, kde nie je potrebná jedinečná implementácia a spoľahlivosť a bezpečnosť sú prioritou.
Druhý aspekt
Ak ste vlastníkom komplexného výpočtového výkonu, obľúbenej služby alebo dátového úložiska pre otvorený alebo polosúkromný prístup, potom by bolo dobrým krokom vytvoriť si vlastné API. Čo to dá:
- Veľký tok klientov.
- Zjednodušený prístup k vašim službám pre partnerov.
- Pohodlie štatistickej analýzy používania služby.
Tretí aspekt
Takmer rovnaký ako druhý. Ale bez potreby implementácie API pre verejný prístup. Ak máte portál a chcete preň vytvoriť mobilnú aplikáciu pre Android/IOS, potom je prepísanie systému na jediné API tým najlepším riešením. Celá dátová štruktúra je systematizovaná. Stránka a aplikácia budú fungovať cez jediné dátové kanály.
Rozhrania API môžu byť zábavné aj frustrujúce zároveň. Na jednej strane interakciou s inými aplikáciami môžete výrazne zvýšiť dosah publika a „wow efekt“ vašej aplikácie. Na druhej strane to zahŕňa čítanie ton dokumentácie, učenie sa o stratégiách autentifikácie a analýzu neinformatívnych (alebo dokonca chýbajúcich) chybových správ.
Po prvé, ak stále úplne nerozumiete tomu, čo je API (Application Programming Interface), prečítajte si vysvetlenie Skillcrush a potom prvú časť tohto článku, aby ste to dohnali.
„API“ je neuveriteľne široký pojem – zakaždým, keď vaša aplikácia „komunikuje“ s inou aplikáciou, je to cez nejaký druh API. Komponenty vo vašej vlastnej aplikácii, podobne ako rôzne časti Rails, spolu tiež komunikujú prostredníctvom API. Sú to viac-menej nezávislé podaplikácie, ktoré prenášajú údaje, ktoré každá potrebuje na vykonávanie svojich vlastných špecifických úloh. Vo svete aplikácií je všetko API!
Keď vytvoríte aplikácie s dynamickejšími front-endovými funkciami (ako jednostránkové Javascriptové aplikácie, tak aj jednoduché aplikácie so samostatnými volaniami AJAX), budú komunikovať s backendom Rails cez vaše vlastné API, čo je v skutočnosti len jeden alebo dva riadky kódu navyše. ., ktorý svojim kontrolórom povie, ako majú poskytovať JSON alebo XML namiesto HTML.
V tomto návode sa naučíte, ako vytvoriť vlastné API. V nasledujúcich lekciách sa budeme zaoberať tým, ako interagovať s rozhraniami API iných aplikácií. Lekcie by mali byť dobrým odrazovým mostíkom pre učenie sa o tejto téme, ale je nepravdepodobné, že budú schopné úplne pokryť všetky prípady. Veľká časť práce s API je schopnosť čítať ich dokumentáciu a zistiť, čo od vás chcú.
Body na zamyslenie
Skontrolujte si otázky a zistite, či poznáte odpovede. Po dokončení úlohy sa znova skontrolujte.
- Ako Rails chápe, aký typ súboru očakávate ako odpoveď, keď odošlete požiadavku HTTP.
- Aký je účel metódy #respond_to?
- Ako vrátite objekt používateľa (User) pri špecifikovaní atribútov, ktoré nechcete zahrnúť do tohto objektu (t. j. nemôžete len vrátiť User.first)?
- Pomenujte 2 kroky zo zákulisia metódy #to_json.
- Ako poviem akcii ovládača, aby zobrazila iba chybové hlásenie?
- Ako vytvoriť vlastnú chybovú správu?
- Prečo nemôžete použiť metódy overovania radiča založené na reláciách, ak chcete povoliť programové pripojenie k vášmu API?
- Čo je to „architektúra orientovaná na služby“?
Základy API
Vaša aplikácia Rails je v skutočnosti už API, aj keď si to možno nemyslíte ako API. Webový prehliadač, ktorý spustia vaši používatelia, je tiež program, takže v skutočnosti odošle požiadavku API do vašej aplikácie Rails, keď používateľ otvorí novú stránku. Máme tendenciu uvažovať týmto spôsobom, pretože vykresľovanie HTML šablón je taká bežná úloha, že túto funkcionalitu jednoducho zakódujeme do našich serverových programov ako štandardný typ odpovede a všetko ostatné považujeme za niečo neobvyklé.
Často však chcete podať žiadosť, ktorá nevyžaduje, aby ste museli prejsť všetkými bolesťami hlavy pri používaní prehliadača. Možno vás nezaujíma štruktúra stránky (HTML), ale na oplátku chcete čisté dáta. Povedzme, že chcete získať zoznam všetkých používateľov. Môžete požiadať o niečo ako http://yourapplication.com/users , čo pravdepodobne spustí akciu #index a vykreslí zoznam všetkých používateľov aplikácie.
Ale prečo sa obťažovať všetkými týmito dodatočnými informáciami, keď všetko, čo chcete, je zoznam používateľov? Najjednoduchšou možnosťou by bolo odoslať požiadavku na rovnakú adresu URL s uvedením očakávanej odpovede JSON alebo XML. Ak správne nastavíte ovládač Rails, získate späť jednoduchý objekt poľa JSON obsahujúci všetkých používateľov. úžasné!
Rovnaký princíp platí, keď komunikujete s externým API. Povedzme, že chcete získať najnovšie „tweety“ používateľa zo služby Twitter. Všetko, čo musíte urobiť, je povedať svojej aplikácii Rails, ako interagovať s rozhraním Twitter API (t. j. overiť sa), odoslať žiadosť a spracovať súbor „tweetov“, ktoré sa vrátia.
Vytvorenie API
Možno budete chcieť zo svojej aplikácie Rails vytvoriť čisté rozhranie API pre frontendové webové stránky, alebo sa jednoducho budete chcieť naučiť, ako odosielať JSON, keď si to front-end vyžiada. Táto časť sa nebude zaoberať tým, ako vytvoriť plnohodnotné RESTful API s funkciou autentifikácie. Toto je hladký úvod do zaobchádzania s vašou aplikáciou ako s API.
Základy
Ak chcete, aby vaša aplikácia Rails vracala JSON namiesto HTML, budete musieť povedať svojmu ovládaču, aby to urobil. Skvelé je, že tá istá akcia ovládača môže vrátiť rôzne typy v závislosti od toho, či váš používateľ zadáva bežnú požiadavku prehliadača alebo pristupuje k API cez príkazový riadok. Toto určuje, aký typ požiadavky bol uskutočnený na základe prípony požadovaného súboru, ako napríklad example.xml alebo example.json .
Môžete skontrolovať, čo si Rails „myslí“ o type súboru, ktorý očakávate, skontrolovaním denníka servera:
Spustenie GET "/posts/new" pre 127.0.0.1 dňa 2013-12-02 15:21:08 -0800 Spracovanie PostsController#new as HTML
Prvý riadok vám povie, aká adresa URL bola požadovaná, a druhý vám povie, kam smerovala a ako s ňou Rails narába. Ak by ste použili rozšírenie .json, vyzeralo by to takto:
Spustenie GET „/posts.json“ pre 127.0.0.1 dňa 2013-12-04 12:02:01 -0800 Spracovanie PostsController#index ako JSON
Ak máte spustenú testovaciu aplikáciu, skúste požiadať o iné adresy URL. Ak váš ovládač nevie, ako s nimi zaobchádzať, môže sa vám zobraziť chyba, ale stále by ste mali byť schopní vidieť, čo Rails rozumie vašim požiadavkám.
Vykresľovanie JSON alebo XML
Keď sa rozhodnete, že chcete odpovedať pomocou JSON alebo XML, budete musieť povedať svojmu kontrolórovi, aby namiesto HTML vykreslil JSON alebo XML. Jedným zo spôsobov, ako to urobiť, je použiť metódu #respond_to:
Trieda 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
V tomto prípade #respond_to odovzdá do bloku objekt formátu, ku ktorému môžete pripojiť príslušné volanie vykresľovania. Ak nič neurobíte, html sa vykreslí pomocou štandardnej šablóny Rails (v tomto príklade app/views/index.html.erb).
Funkcia #render je dostatočne inteligentná na to, aby pochopila, ako vykresliť širokú škálu formátov. Keď mu odovzdáte kľúč:json , zavolá #to_json na hodnote, v tomto príklade @users . Týmto sa vaše objekty Ruby skonvertujú na reťazce JSON, ktoré budú odovzdané žiadajúcej aplikácii.
Takto získate svoje API. Samozrejme, vytvorenie API môže byť trochu komplikovanejšie, ak chcete robiť nejaké fantastické veci, ale je to všetko o základoch.
Zadanie atribútov vrátenia
Povedzme, že sa chcete uistiť, že nevraciate e-mailovú adresu používateľa spolu s objektom používateľa. V tomto prípade budete chcieť zmeniť atribúty, ktoré budú vrátené, a upraviť to, čo robí metóda #to_json.
Predtým by ste jednoducho prepísali metódu #to_json svojou verziou, ale teraz to už nemusíte – v skutočnosti namiesto toho prepíšete metódu #as_json. Metóda #as_json sa používa v metóde #to_json, takže jej úpravou sa implicitne zmení výsledok #to_json , ale dosť špecifickým spôsobom.
#to_json robí 2 veci: spustí #as_json a získa hash atribútov, ktoré sa majú vykresliť do JSON. Potom sa vykreslí do JSON pomocou ActiveSupport::json.encode. Takže úpravou #as_json ste konkrétnejší v časti metódy #to_json, ktorú chcete skutočne zmeniť.
V našom prípade to robíme úpravou #as_json v našom modeli tak, aby vrátil iba atribúty, ktoré potrebujeme:
# app/models/user.rb class User< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # NEZAHRŇUJTE pole email end # Možnosť 2: Použite štandardnú metódu #as_json def as_json(options=()) super(iba: [:meno]) end end
Potom v našom ovládači všetko, čo musíme urobiť, je vykresliť JSON ako zvyčajne (príklad nižšie vždy vráti JSON, či už bola odoslaná požiadavka HTML alebo nie):
# app/controllers/users_controller.rb trieda UsersController< ApplicationController def index render json: User.all end end
Všimnite si, že pri použití #render nemusíte sami volať #to_json – urobí to za vás.
Heroku môže niekedy vyžadovať ďalšie kroky na správne zobrazenie vašich chybových stránok. Pozri. Možno budete musieť najskôr odstrániť statické stránky z adresára app/public.
Zabezpečenie zvonku
Povedzme, že chcete povoliť prístup k API iba vtedy, ak je používateľ prihlásený. Vaša existujúca autentifikácia ovládača už funguje – len sa uistite, že máte nastavenú správnu #before_action (napr. before_action:require_login). Možno budete chcieť funkcionalitu, pri ktorej si stránku môžu prezerať prihlásení aj neprihlásení používatelia, ale každý potrebuje vidieť iné údaje. Nechcete, aby neprihlásení používatelia mohli zadávať požiadavky API na získanie citlivých údajov. Podobne nechcete povoliť neautorizovaným používateľom návštevu určitých stránok HTML.
Ak chcete spracovať požiadavky z aplikácie, ktorá nie je v prehliadači (napríklad z príkazového riadku), nemôžete sa pri overovaní spoliehať na súbory cookie prehliadača. To je dôvod, prečo väčšina rozhraní API používa natívne tokeny ako súčasť procesu autentifikácie. O tokenoch si povieme niečo viac v nasledujúcej lekcii.
Ďalšie kroky
Teraz máte schopnosti používať svoju aplikáciu Rails na poskytovanie nielen HTML, ale aj akéhokoľvek iného formátu. Ak chcete ísť ešte ďalej a nechať iných vývojárov vytvárať veci pomocou vašej platformy (napríklad, aby mohli vytvárať programové požiadavky namiesto overovania ako používateľ), budete musieť svoj systém API zabezpečiť oveľa bezpečnejším. Nebudeme sa tu zaoberať všetkým, ale pozrite sa na nasledujúce:
- Článok Building Awesome Rails APIs popisuje mnohé z najlepších prístupov na prechod z hračkárskej aplikácie na priemyselné štandardné rozhrania API.
Architektúra orientovaná na služby
Je čas predstaviť architektonický prístup s názvom Service-Oriented Architecture (SOA). Základnou myšlienkou je, že vaša aplikácia bude pozostávať z mnohých služieb, ako je platobný systém, registrácia používateľov, modul odporúčaní atď. Namiesto toho, aby ste to všetko budovali v rámci jednej hlavnej aplikácie, rozdeľujete podsystémy na úplne nezávislé časti, ktoré navzájom spolupracujú pomocou interných rozhraní API.
To je dobré z mnohých dôvodov. Zabezpečením toho, že každej časti vašej aplikácie nezáleží na tom, ako fungujú ostatné časti, a bude vedieť, ako požiadať o údaje iba prostredníctvom svojho API, môžete vykonať významné zmeny v servisnom kóde a zvyšok aplikácie bude fungovať ako predtým. Jednu službu môžete úplne nahradiť inou a pokiaľ komunikuje pomocou rovnakých metód API, pôjde to veľmi hladko. Môžete použiť externé API ako súčasť vašej aplikácie (napríklad platobné systémy) namiesto písania vlastných. Môžete vytvoriť aplikáciu PHP, ktorá spolupracuje s aplikáciou Python, ktorá spolupracuje s aplikáciou Rails, a všetko bude fungovať, pretože medzi sebou komunikujú pomocou API.
Vo všeobecnosti je dobré snažiť sa, aby každá časť vašej aplikácie bola čo najviac nezávislá. Koncept SOA vás nabáda, aby ste premýšľali presne o tom, aké metódy chcete vystaviť iným častiam vašej aplikácie, a tým vylepšíte svoj kód. Navyše, za predpokladu, že každý hlavný komponent vašej aplikácie je nezávislý, môžete tiež oveľa jednoduchšie izolovať problémy a inteligentnejšie riešiť chyby.
Použitie architektúry orientovanej na služby pre celú aplikáciu je ako rozloženie obrovského, zložitého skriptu Ruby na šikovné triedy a metódy, len vo väčšom meradle.
Jedným z najznámejších prípadov prechodu na architektúru orientovanú na služby je Amazon.com. Jedného dňa v roku 2002 Jeff Bezos otvorene vyhlásil, že všetky pracovné tímy musia prejsť na SOA, inak budú prepustené. Notoricky známy príspevok v blogu zamestnanec spoločnosti Google, určený na interné účely, ale náhodne vystavený verejnosti, hovoril o sile Amazonu pomocou SOA. Toto je skvelé čítanie, takže ho určite ohodnoťte, ale hlavné tézy Bezosovho listu sú vyňaté z nasledujúcich citátov z príspevku:
1) Všetky príkazy teraz poskytujú svoje údaje a funkcie prostredníctvom servisných rozhraní.
2) Tímy musia medzi sebou komunikovať prostredníctvom týchto rozhraní.
3) Iné formy medziprocesovej komunikácie sú zakázané: žiadne priame prepojenia, žiadne priame čítanie údajov z iného príkazu, žiadne modely zdieľanej pamäte, žiadne „zadné vrátka“ a podobne. Jediným povoleným spôsobom komunikácie je prístup k rozhraniu služby cez sieť.
4) Nezáleží na tom, akú technológiu používajú. HTTP, Corba, Pubsub, natívne protokoly – na tom nezáleží. Bezosovi je to jedno.
5) Všetky servisné rozhrania bez výnimky musia byť pôvodne navrhnuté tak, aby bolo možné ich ovládať zvonku. To znamená, že tím musí plánovať a navrhovať, aby bol schopný poskytnúť rozhranie pre vývojárov mimo spoločnosti. Bez výnimky.
6) Každý, kto bude ignorovať tieto požiadavky, bude prepustený.
SOA je seriózna záležitosť. Iste, existuje veľa problémov, ktoré sa vyskytnú pri jeho používaní - pozrite si tento príspevok o "poučeniach" Amazonu - ale má neuveriteľné množstvo výhod.
Počas vytvárania „hračkových“ aplikácií si so SOA pravdepodobne nebudete príliš lámať hlavu, no táto otázka vás určite napadne, keď začnete pracovať pre IT spoločnosť, takže oboznámenie sa s ňou je dobrou praxou.
Váš cieľ
- Prečítajte si časť 7 príručky Rails Guide to Controllers, kde sa dozviete o vykresľovaní JSON a XML.
- Nevyžaduje sa ich prezeranie (pretože idú o niečo ďalej, ako máme v súčasnosti), ale ak máte záujem, pozrite si Railscasts v sekcii Ďalšie zdroje v spodnej časti návodu, kde sa dozviete viac o výhodách API.
Záver
Počas kurzu Javascript budeme užšie spolupracovať s vašou aplikáciou ako API. V tomto kurze vytvoríte niekoľko úplných aplikácií, ktoré používajú volania AJAX pre lepšiu používateľskú skúsenosť, čo v skutočnosti zahŕňa vykresľovanie údajov XML alebo JSON namiesto úplnej stránky HTML. Ďalej vytvoríte niekoľko jednostránkových aplikácií Javascript, ktoré sa spoliehajú na API poskytované vašou aplikáciou Rails, aby získali všetky potrebné údaje z databázy a inak sa spúšťajú na strane klienta (v prehliadači).
Najlepší spôsob, ako sa vysporiadať s API, je vytvoriť ho a interagovať s ním, na čo sa zameriame v našich projektoch.
pozdravujem!
V tomto článku zvážime, čo je API, kde, ako a na čo sa používa. Pozrieme sa tiež na to, ako sa dá API využiť pri vývoji webu a ako môže uľahčiť život webovým programátorom.
Začnime teda definíciou. API (Application Programming Interface) je programovacie rozhranie, rozhranie na vytváranie aplikácií. V zrozumiteľnejšom jazyku je API hotový kód na zjednodušenie života programátora. Rozhranie API bolo vytvorené tak, aby programátor mohol skutočne uľahčiť písanie tejto alebo tej aplikácie pomocou hotového kódu (napríklad funkcií). Známy jQuery napísaný v JavaScripte je tiež akýmsi API. Ak vezmeme do úvahy tento konkrétny príklad, potom jQuery značne uľahčuje písanie kódu. To, čo by sa dalo urobiť v 30 riadkoch s bežnými JavaScriptovými nástrojmi, je napísané cez jQuery v 5-6. Ak vezmeme do úvahy API vo všeobecnosti, potom môžete nájsť veľa služieb, ktoré predstavujú vývojové riešenia. Najznámejšia je dnes služba code.google.com, ktorá poskytuje asi päťdesiat rôznych API! Ide o rozhranie na vytváranie aplikácií pre Android a rôzne API pre prácu s AJAX a rôzne aplikačné API, ktoré je možné jednoducho prispôsobiť podľa vašich predstáv.
Koniec koncov, má zmysel písať kód vlastnými rukami? Prečo pracovať na tom, čo už bolo vytvorené? Má zmysel odmietnuť bezplatné riešenia (a vlastne bezplatnú pomoc) pri vývoji webu? Ak ste na všetky tieto otázky odpovedali „NIE“, zvážte, že rozumiete podstate API.
Ale chcem si to aj ujasniť. Začiatočníci vývojári by NEMALI používať polotovary, pretože v budúcnosti nezvládnu skutočnú úlohu. Preto ak ste začínajúci webový programátor, tak nepoužívajte polotovary! Naučte sa myslieť hlavou, zostavte rôzne algoritmy, aby ste pochopili podstatu programovania. Tiež hovorím, už oslovujem všetkých, že API nie je hotové riešenie, je to prostredie, rozhranie na vytváranie vlastných projektov. Ty neješ mrazené fašírky z obchodu, však? Najprv ich opečieš, však? Táto analógia veľmi jasne vystihuje podstatu API.
Vo všeobecnosti som povedal, čo je API, kde a ako sa používa, čo je najdôležitejšie, na čo. Prajem Vám príjemné štúdium programovania webu a pochopenie jeho väčších hĺbok!
Žiadne značky
Tento článok nie je predmetom komentárov, pretože jeho autor ešte nie je riadnym členom komunity. Autora budete môcť kontaktovať až po prijatí
