API-ul definește funcționalitatea pe care o oferă un program (modul, bibliotecă), în timp ce API-ul vă permite să faceți abstracție de la modul exact în care este implementată această funcționalitate.

Dacă un program (modul, bibliotecă) este considerat o cutie neagră, atunci API-ul este un set de „mânere” care sunt disponibile utilizatorului acestei casete, pe care le poate învârti și trage.

Componentele software interacționează între ele prin intermediul API-urilor. În acest caz, componentele formează de obicei o ierarhie - componentele de nivel înalt folosesc API-ul componentelor de nivel scăzut și, la rândul lor, folosesc API-ul componentelor de nivel inferior.

Protocoalele de transfer de date sunt construite pe acest principiu. Protocolul Internet standard (modelul de rețea OSI) conține 7 straturi (de la nivelul fizic al pachetelor de biți de transmisie la nivelul protocoalelor de aplicație, cum ar fi protocoalele HTTP și IMAP). Fiecare strat folosește funcționalitatea stratului anterior de transfer de date și, la rândul său, oferă funcționalitatea necesară stratului următor.

Este important de reținut că conceptul de protocol este apropiat ca înțeles de conceptul de API. Ambele sunt abstracții ale funcționalității, doar că în primul caz vorbim de transfer de date, iar în al doilea vorbim despre construirea de aplicații informatice.

API-ul bibliotecii de funcții și clase include o descriere semnăturiȘi semantica functiilor.

Interfața de programare a aplicațiilor (API) este o interfață software pentru interacțiunea între sisteme, care permite:

• Obțineți acces la serviciile de afaceri pentru întreprinderi
• Schimb de informații între sisteme și aplicații
• Simplificați interacțiunile dintre companii, parteneri, dezvoltatori și clienți

Deschideți strategia API

Strategia API include:

• Dezvoltarea de produse de afaceri bazate pe API-urile existente
• Furnizarea de servicii interne pentru dezvoltatori
• Modele de monetizare API pentru construirea de interacțiuni multicanal și creșterea profiturilor

Implementarea conceptului Open API ajută la transformarea afacerii, la integrarea într-un ecosistem flexibil de proiecte al jucătorilor de pe piață, la crearea condițiilor pentru generarea constantă de idei noi și crearea de valoare suplimentară atunci când gestionați matrice de date corporative.

Piața soluțiilor de integrare se dezvoltă în contextul evoluției API-urilor - de la EDI și SOAP la Web 2.0, care a început era API-urilor publice. Numărul de astfel de interfețe în următorii 3 ani poate crește de peste 50 de ori și poate ajunge la 1 milion. Acest lucru se datorează omnicanalului: canalele de interacțiune cu clienții trebuie să se schimbe odată cu ei. Creșterea continuă a numărului de consumatori și a volumului de date a dus la apariția economiei API, care ajută la crearea modelelor de afaceri inovatoare pentru utilizarea activelor și serviciilor întreprinderii bazate pe interfețe deschise.

Semnătura funcției

Semnătura funcției- parte a unei declarații generale de funcție care permite radiodifuzorilor să identifice funcția printre altele. Diferite limbaje de programare au idei diferite despre semnătura unei funcții, care este, de asemenea, strâns legată de capacitățile de supraîncărcare a funcției în aceste limbi.

Uneori se disting semnătură de apelȘi semnătură de implementare funcții. O semnătură de apel este de obicei compilată din structura sintactică a unui apel de funcție, ținând cont de semnătura domeniului de aplicare al funcției date, numele funcției, secvența de tipuri reale de argumente din apel și tipul de rezultat. Semnătura de implementare include de obicei câteva elemente din structura sintactică a declarației funcției: un specificator al domeniului funcției, numele acesteia și o secvență de tipuri de argumente formale.

De exemplu, în limbajul de programare C++, o funcție simplă este identificată în mod unic de către compilator prin numele și secvența de tipuri a argumentelor sale, care constituie semnătura funcției în acest limbaj. Dacă o funcție este o metodă a unei anumite clase, atunci și numele clasei va fi inclus în semnătură.

De asemenea, trebuie remarcat faptul că programatorul are adesea la dispoziție mai multe API-uri diferite pentru a obține același rezultat. Mai mult, fiecare API este de obicei implementat folosind componente software API de un nivel inferior de abstractizare.

De exemplu: pentru a vedea linia „Bună, lume!” în browser. Tot ce trebuie să faceți este să creați un document HTML cu un titlu minim și un corp simplu care să conțină această linie. Ce se întâmplă când browserul deschide acest document? Programul browser va transmite numele fișierului (sau un descriptor de fișier deja deschis) bibliotecii care prelucrează documentele HTML, care, la rândul său, folosind API-ul sistemului de operare, va citi acest fișier și va înțelege structura acestuia, apelând operațiuni precum „clear the fereastră”, „scrie Bună, lume în fontul selectat!”, în timpul acestor operațiuni biblioteca de primitive grafice va contacta biblioteca interfeței ferestrei cu solicitările corespunzătoare, iar această bibliotecă va contacta API-ul sistemului de operare cu solicitări precum „pune-l în placa mea video tamponează asta".

Mai mult, la aproape fiecare nivel există de fapt mai multe API-uri alternative posibile. De exemplu: am putea scrie documentul sursă nu în HTML, ci în LaTeX și am putea folosi orice browser pentru afișare. Diferitele browsere folosesc în general biblioteci HTML diferite și, în plus, totul poate fi compilat (în general vorbind) folosind diferite biblioteci primitive și pe sisteme de operare diferite.

Prin urmare, principalele provocări ale sistemelor API pe mai multe niveluri existente sunt:

• Dificultate în portarea codului programului de la un sistem API la altul (de exemplu, la schimbarea sistemului de operare);
• Pierderea funcționalității la trecerea de la un nivel inferior la unul superior. În linii mari, fiecare „layer” API este creat pentru a facilita execuția unui set standard de operațiuni. Dar, în același timp, devine cu adevărat dificil sau devine fundamental imposibil să efectuați alte operațiuni care sunt furnizate de un nivel inferior de API.

Tipuri de API de bază

API-uri interne

• Accesul la API este limitat doar la dezvoltatorii interni
• Aplicațiile sunt destinate angajaților întreprinderii

Factori de afaceri:

• Consecvența dezvoltării
• Reducerea costurilor
• Creșterea eficienței dezvoltării

API-uri pentru parteneri

• API-urile sunt disponibile numai pentru un set limitat de parteneri de afaceri
• Aplicațiile sunt destinate consumatorilor finali și utilizatorilor de afaceri

Factori de afaceri:

• Automatizarea procesului de dezvoltare
• Dezvoltarea parteneriatelor
• Optimizarea procesului de interactiune cu partenerii

API-uri publice

Accesul este acordat oricărui dezvoltator extern Aplicațiile sunt destinate utilizatorilor finali

Factori de afaceri:

• Dezvoltarea de noi servicii
• Dezvoltarea ecosistemului
• Interacțiune omnicanal

Cele mai cunoscute API-uri

Sisteme de operare API

GUI API

• Direct3D (parte a DirectX)
• DirectDraw (parte a DirectX)

Să începem cu elementele de bază: ce este un API? Abrevierea înseamnă Interfață de programare a aplicațiilor sau interfață pentru programarea aplicațiilor. Numele pare să vorbească de la sine, dar este mai bine să luați în considerare o explicație mai detaliată.

După cum am menționat deja, un API este, în primul rând, o interfață. O interfață care permite dezvoltatorilor să folosească blocuri gata făcute pentru a construi o aplicație. În cazul dezvoltării aplicațiilor mobile, o bibliotecă pentru lucrul cu o casă inteligentă poate acționa ca API - toate nuanțele sunt implementate în bibliotecă și accesați acest API doar în codul dvs.

În cazul aplicațiilor web, API-ul poate returna date într-un alt format decât HTML standard, făcându-l ușor de utilizat atunci când scrieți propriile aplicații. API-urile publice terțe oferă cel mai adesea date în unul dintre cele două formate: XML sau JSON. În cazul în care decideți să faceți un API pentru aplicația dvs., amintiți-vă că JSON este mult mai concis și mai ușor de citit decât XML, iar serviciile care oferă acces la date în format XML îl abandonează treptat pe acesta din urmă.

API în aplicații web cu exemple

O aplicație - de exemplu, Github - are propriul API pe care alți dezvoltatori îl pot folosi. Modul în care îl vor folosi depinde de capacitățile pe care API-ul le oferă și de cât de bine funcționează imaginația dezvoltatorilor. API-ul GitHub permite, de exemplu, obținerea de informații despre utilizator, avatarul acestuia, cititori, depozite și multe alte informații utile și interesante.

Într-un mod similar, puteți trimite o solicitare în orice limbă, inclusiv în Ruby. Răspunsul la cerere va fi aproximativ următoarele informații:

( „login” : „Freika” , „id” : 3738638, „avatar_url” : „https://avatars.githubusercontent.com/u/3738638?v=3”, "gravatar_id" : "" , "url": „https://api.github.com/users/Freika”, "html_url" : "https://github.com/Freika" , "followers_url" : „https://api.github.com/users/Freika/followers”, „following_url”: „https://api.github.com/users/Freika/following(/other_user)”, "gists_url" : „https://api.github.com/users/Freika/gists(/gist_id)”, "starred_url" : „https://api.github.com/users/Freika/starred(/owner)(/repo)”, "subscriptions_url" : „https://api.github.com/users/Freika/subscriptions”, "organizations_url" : „https://api.github.com/users/Freika/orgs”, "repos_url": „https://api.github.com/users/Freika/repos”, "events_url" : „https://api.github.com/users/Freika/events(/privacy)”, "received_events_url" : „https://api.github.com/users/Freika/received_events”, "type" : "Utilizator" , "site_admin" : false , "name" : "Evgeniy" , "company" : "" , "blog" : "http://frey.su/" , "location" : " Barnaul" , "email" : "" , "hireable" : true , "bio" : null, "public_repos" : 39, "public_gists" : 13, "followers" : 15, "following" : 21, "created_at" : "2013-03-01T13:48:52Z" , "updated_at" : "2014-12-15T13:55:03Z" )

După cum se poate observa din blocul de mai sus, răspunsul conține autentificare, avatar, link către profilul de pe site și în API, starea utilizatorului, numărul de depozite publice și alte informații utile și interesante.

Numai API-ul nu este suficient

Crearea unui API cu drepturi depline pentru aplicația dvs. este doar jumătate din luptă. Cum ar trebui să accesați API-ul? Cum îl vor accesa utilizatorii?

Primul lucru care îmi vine în minte este seria obișnuită de solicitări HTTP pentru a obține informațiile dorite, iar acesta este răspunsul greșit. Metoda cea mai evidentă în acest caz nu este cea mai convenabilă și simplă. Ar fi mult mai rezonabil să se creeze o bibliotecă specială pentru lucrul cu interfața, care să descrie toate modalitățile necesare de a primi și trimite informații folosind API-ul.

Să folosim încă o dată Github pentru a da un exemplu: pentru a lucra cu API-ul acestui serviciu excelent (și interfața sa oferă capabilități extinse), au fost create mai multe biblioteci în diferite limbi, de exemplu bijuteria Octokit. În documentația pentru astfel de biblioteci (și bijuteria dată ca exemplu), orice dezvoltator interesat va putea găsi toate modalitățile necesare pentru a primi informații de la Github și a le trimite înapoi prin API-ul serviciului.

Astfel, dacă vă creați propriul API, luați în considerare posibilitatea de a crea biblioteci pentru a lucra cu el în cele mai comune limbi. Și fiți pregătit ca la un anumit nivel de cerere pentru aplicația dvs., altcineva își poate crea propria bibliotecă pentru a lucra cu API-ul dvs. Este în regulă.

Link-uri utile

În articolele următoare vom vorbi despre cum să creați corect un API, să asigurați securitatea acestuia și să limitați accesul la unele informații.

Lucrul cu API-uri poate fi atât satisfăcător, cât și frustrant. Pe de o parte, interacționând cu alte aplicații, puteți crește considerabil acoperirea publicului și efectul „wow” al aplicației dumneavoastră. Pe de altă parte, aceasta implică citirea de tone de documentație, studierea strategiilor de autentificare și analizarea mesajelor de eroare neinformative (sau chiar lipsă).

În primul rând, dacă încă nu înțelegi pe deplin ce este un API (Application Programming Interface), citește explicația Skillcrush și apoi prima parte a acestui articol pentru a prinde din urmă.

„API” este un concept incredibil de larg - de fiecare dată când aplicația ta „vorbește” cu o altă aplicație, o face printr-un fel de API. Componentele din propria aplicație, cum ar fi diferite părți ale Rails, vorbesc între ele prin intermediul API-urilor. Sunt subaplicații mai mult sau mai puțin independente care oferă datele de care fiecare dintre ele are nevoie pentru a-și îndeplini propriile sarcini specifice. În lumea aplicațiilor, totul este un API!

Când construiți aplicații cu funcționalitate front-end mai dinamică (atât aplicații Javascript cu o singură pagină, cât și aplicații simple cu apeluri AJAX individuale), acestea vor comunica cu backend-ul Rails prin propriul dvs. API, care este de fapt doar o linie suplimentară sau două de cod. , spunându-le controlorilor cum să difuzeze JSON sau XML în loc de HTML.

În acest tutorial veți învăța cum să vă creați propriul API. În lecțiile ulterioare vom aborda modul de a interacționa cu API-urile altor aplicații. Lecțiile ar trebui să fie o bună rampă pentru a învăța despre acest subiect, dar este puțin probabil să acopere pe deplin toate cazurile. O mare parte a lucrului cu API-urile este să știi cum să le citești documentația și să-ți dai seama ce vor de la tine.

Puncte de luat în considerare

Examinați întrebările și vedeți dacă știți răspunsurile. Testează-te din nou după finalizarea sarcinii.

• Cum înțelege Rails ce tip de fișier așteptați ca răspuns atunci când trimiteți o solicitare HTTP.
• Care este scopul metodei #respond_to?
• Cum returnați un obiect User în timp ce specificați atributele pe care nu doriți să le includă în acel obiect (adică nu puteți returna doar User.first)?
• Denumiți cei 2 pași din culisele metodei #to_json.
• Cum îi spui unei acțiuni controlerului să redea doar un mesaj de eroare?
• Cum să-ți creezi propriul mesaj de eroare?
• De ce nu puteți utiliza metode de autentificare a controlerului bazate pe sesiune dacă doriți să permiteți conexiuni programatice la API-ul dvs.?
• Ce este „Arhitectura Orientată pe Servicii”?

Bazele API

Aplicația dvs. Rails este de fapt deja un API, deși s-ar putea să nu o considerați un API. Browserul web lansat de utilizatorii dvs. este, de asemenea, un program, astfel încât de fapt face o solicitare API către aplicația dvs. Rails atunci când utilizatorul deschide o pagină nouă. Avem tendința de a gândi în acest fel, deoarece redarea șabloanelor HTML este o sarcină atât de comună încât pur și simplu introducem această funcționalitate în programele noastre de server ca tip de răspuns standard și considerăm că orice altceva este ceva neobișnuit.

Cu toate acestea, de multe ori doriți să faceți o solicitare care nu vă cere să treceți prin toate durerile de cap ale utilizării unui browser. Poate că nu vă pasă de structura paginii (HTML), dar în schimb doriți date curate. Să presupunem că doriți să obțineți o listă cu toți utilizatorii. Puteți solicita ceva de genul http://yourapplication.com/users , care va declanșa cu siguranță acțiunea #index și va afișa o listă cu toți utilizatorii aplicației.

Dar de ce să vă deranjați cu toate aceste informații suplimentare dacă tot ce doriți este o listă de utilizatori? Cea mai simplă opțiune ar fi să trimiteți o solicitare la aceeași adresă URL și să așteptați în schimb un răspuns JSON sau XML. Dacă vă configurați corect controlerul Rails, veți primi înapoi un obiect simplu matrice JSON care conține toți utilizatorii. Minunat!

Același principiu se aplică atunci când comunicați cu un API extern. Să presupunem că doriți să obțineți tweet-urile recente ale unui utilizator de pe Twitter. Tot ce trebuie să faceți este să spuneți aplicației dvs. Rails cum să interacționeze cu API-ul Twitter (adică să vă autentificați), să trimiteți cererea și să procesați setul de „tweeturi” care vor fi returnate.

Crearea unui API

Este posibil să doriți să faceți din aplicația dvs. Rails un API backend pur pentru paginile web frontend sau poate doriți doar să aflați cum să trimiteți JSON atunci când interfața vă solicită acest lucru. Această secțiune nu va acoperi cum să creați API-uri RESTful cu drepturi depline cu funcții de autentificare. Aceasta este o introducere simplă în tratarea aplicației dvs. ca API.

Bazele

Dacă doriți ca aplicația dvs. Rails să returneze JSON în loc de HTML, va trebui să spuneți controlerului dvs. să facă acest lucru. Lucrul grozav este că aceeași acțiune a controlerului poate returna tipuri diferite, în funcție de dacă utilizatorul face o solicitare regulată din browser sau accesează API-ul prin linia de comandă. Aceasta determină ce tip de solicitare a fost făcută pe baza extensiei fișierului solicitat, cum ar fi example.xml sau example.json.

Puteți verifica ce crede Rails despre tipul de fișier pe care îl așteptați verificând jurnalul serverului:

A început GET „/posts/new” pentru 127.0.0.1 la 2013-12-02 15:21:08 -0800 Procesarea de către PostsController#new ca HTML

Prima linie vă spune ce URL a fost solicitată, iar a doua vă spune unde a fost trimisă și cum o procesează Rails. Dacă ar fi să utilizați extensia .json, ar arăta astfel:

A început GET „/posts.json” pentru 127.0.0.1 la 2013-12-04 12:02:01 -0800 Procesarea de către PostsController#index ca JSON

Dacă rulați o aplicație de testare, încercați să solicitați adrese URL diferite. Dacă controlerul dvs. nu le poate gestiona, este posibil să primiți o eroare, dar ar trebui să puteți vedea în continuare ce înțelege Rails că sunt cererile dvs.

Redare JSON sau XML

Odată ce decideți că doriți să răspundeți la solicitări folosind JSON sau XML, va trebui să spuneți controlerului dvs. să redeze JSON sau XML în loc de HTML. O modalitate de a face acest lucru este să utilizați metoda #respond_to:

Clasa 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

În acest caz, #respond_to transmite blocului un obiect format, căruia îi puteți atașa un apel de randare corespunzător. Dacă nu faceți nimic, codul html va fi redat folosind șablonul standard Rails (în acest exemplu app/views/index.html.erb).

Funcția #render este suficient de inteligentă pentru a înțelege cum să redați o gamă largă de formate. Când îi transmiteți cheia:json , va apela #to_json pe valoarea, în acest exemplu @users . Aceasta va converti obiectele dvs. Ruby în șiruri JSON care vor fi transmise aplicației solicitante.

În acest fel, obțineți API-ul dvs. Desigur, crearea unui API poate fi puțin mai complexă dacă doriți să faceți niște lucruri fanteziste, dar totul se lipește de elementele de bază.

Specificarea atributelor returnate

Să presupunem că doriți să vă asigurați că nu returnați adresa de e-mail a utilizatorului împreună cu obiectul Utilizator. În acest caz, veți dori să modificați atributele care vor fi returnate, modificând ceea ce face metoda #to_json.

Anterior, ați fi înlocuit pur și simplu metoda #to_json cu versiunea dvs., dar acum nu va fi nevoie - de fapt, veți înlocui metoda #as_json. Metoda #as_json este folosită în metoda #to_json, deci modificarea acesteia modifică implicit rezultatul #to_json , dar într-un mod destul de specific.

#to_json face 2 lucruri: rulează #as_json și primește un hash al atributelor care vor fi redate în JSON. Apoi se redă în JSON folosind ActiveSupport::json.encode . Deci, modificând #as_json, sunteți mai precis cu privire la partea din metoda #to_json pe care doriți să o modificați.

În cazul nostru, facem acest lucru modificând #as_json în modelul nostru pentru a returna numai atributele de care avem nevoie:

# app/models/user.rb clasa Utilizator< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # NU includeți câmpul de e-mail end # Opțiunea 2: Folosiți metoda standard #as_json def as_json(options=()) super(only: [:name]) end end

Apoi, controlerul nostru va trebui doar să redea JSON ca de obicei (în exemplul de mai jos, JSON va fi întotdeauna returnat, indiferent dacă a fost trimisă sau nu o solicitare HTML):

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

Rețineți că nu trebuie să apelați singur #to_json când utilizați #render - va face acest lucru pentru dvs.

Uneori, Heroku poate necesita pași suplimentari pentru a afișa corect paginile de eroare. Aruncă o privire. Poate fi necesar să eliminați mai întâi paginile statice din aplicația/directorul public.

Asigurarea securității din exterior

Să presupunem că doriți să permiteți accesul la API numai dacă utilizatorul este conectat. Autentificarea dvs. existentă în controler face deja această treabă - asigurați-vă doar că aveți setul corect #before_action (de exemplu, before_action:require_login). Este posibil să aveți nevoie de funcționalitate în care atât utilizatorii conectați, cât și cei neconectați să poată vizualiza pagina, dar fiecare ar trebui să vadă date diferite. Nu doriți ca utilizatorii neautentificați să poată efectua apeluri API pentru a obține date sensibile. De asemenea, nu doriți să permiteți utilizatorilor neautorizați să viziteze anumite pagini HTML.

Dacă doriți să procesați cereri de la o aplicație care nu este un browser (de exemplu, din linia de comandă), nu vă puteți baza pe „cookie-urile” browserului pentru autentificare. Acesta este motivul pentru care majoritatea API-urilor folosesc token-uri native ca parte a procesului de autentificare. Vom vorbi mai mult despre jetoane în lecția următoare.

Pasii urmatori

Acum aveți abilitățile de a utiliza aplicația Rails pentru a reda nu numai HTML, ci și orice alt format. Dacă doriți să mergeți mai departe și să permiteți altor dezvoltatori să construiască lucruri folosind platforma dvs. (de exemplu, pentru a putea face solicitări programatice în loc să se autentifice ca utilizator), va trebui să vă faceți sistemul API mult mai robust. Nu vom acoperi totul aici, dar verificați următoarele:

• Articolul Building Awesome Rails API-uri descrie multe dintre cele mai bune abordări pentru trecerea de la o aplicație de jucărie la standardele API industriale.

Arhitectura orientată spre servicii

Este timpul să introducem o abordare arhitecturală numită Arhitectură Orientată pe Servicii (SOA). Ideea de bază este că aplicația dumneavoastră va consta din multe servicii, precum un sistem de plată, înregistrarea utilizatorilor, modul de recomandare etc. În loc să construiți totul într-o singură aplicație principală, împărțiți subsistemele în bucăți complet independente care comunică între ele folosind API-uri interne.

Acest lucru este bun din multe motive. Deoarece fiecărei părți a aplicației dumneavoastră nu îi pasă de modul în care funcționează celelalte părți și știe doar cum să solicite date prin intermediul API-ului lor, puteți face modificări semnificative codului de serviciu, iar restul aplicației va funcționa ca înainte. Puteți înlocui complet un serviciu cu altul și, atâta timp cât comunică folosind aceleași metode API, va funcționa foarte bine. Puteți utiliza API-uri externe ca parte a aplicației dvs. (de exemplu, sisteme de plată) în loc să le scrieți pe ale dvs. Puteți crea o aplicație PHP care comunică cu o aplicație Python care comunică cu o aplicație Rails și totul va funcționa deoarece comunică între ei folosind un API.

În general, este o idee bună să încercați să faceți fiecare parte a aplicației dvs. cât mai independentă posibil. Conceptul de SOA te obligă să te gândești în ceea ce privește metodele pe care vrei să le expui altor părți ale aplicației tale, ceea ce îți va îmbunătăți codul. În plus, presupunând că fiecare componentă majoră a aplicației dumneavoastră este independentă, veți putea, de asemenea, să izolați problemele mult mai ușor și să gestionați erorile într-un mod mai semnificativ.

Utilizarea unei arhitecturi orientate spre servicii pentru o întreagă aplicație este ca și cum a despărți un script Ruby uriaș și complex în clase și metode ordonate, doar la scară mai mare.

Unul dintre cele mai cunoscute cazuri de tranziție la arhitectura orientată spre servicii este Amazon.com. Într-o zi din 2002, Jeff Bezos a declarat fără îndoială că toate grupurile de lucru trebuie să treacă la SOA sau să fie concediate. Notoriu postare pe blog Angajatul Google, destinat în scopuri interne, dar făcut public din greșeală, a vorbit despre puterea Amazon folosind SOA. Este o lectură grozavă, așa că asigurați-vă că o verificați, dar punctele principale ale scrisorii lui Bezos sunt rezumate în următoarele citate din postare:

1) Toate echipele își oferă acum datele și funcționalitățile prin interfețele de servicii.

2) Echipele trebuie să comunice între ele prin aceste interfețe.

3) Sunt interzise alte forme de comunicare între procese: fără legături directe, fără citire directă a datelor unei alte comenzi, fără modele de memorie partajată, fără uși din spate etc. Singura modalitate de interacțiune permisă este accesarea interfeței de serviciu prin rețea.

4) Nu contează ce tehnologie folosesc. HTTP, Corba, Pubsub, protocoale proprietare - nicio diferență. Lui Bezos nu-i pasă.

5) Toate interfețele de service, fără excepție, trebuie să fie proiectate inițial cu capacitatea de a fi controlate extern. Adică, echipa trebuie să planifice și să proiecteze pentru a putea oferi interfața dezvoltatorilor din afara companiei. Fara exceptii.

6) Oricine ignoră aceste cerințe va fi concediat.

SOA este o afacere serioasă. Sigur, există o mulțime de probleme care apar atunci când îl utilizați - consultați această postare despre „lecțiile învățate” de la Amazon - dar are o cantitate incredibilă de beneficii.

Probabil că nu vă veți face prea multe griji cu privire la SOA în timp ce construiți aplicații de jucărie pentru dvs., dar este cu siguranță o problemă care va apărea atunci când începeți să lucrați pentru o companie IT, așa că familiarizarea cu aceasta este o bună practică.

Scopul tău

1. Citiți Secțiunea 7 din Ghidul controlerelor șine pentru a afla despre randarea JSON și XML.
2. Nu sunt obligatorii vizionare (pentru că merg puțin mai departe decât suntem pregătiți în prezent), dar dacă sunteți interesat, aruncați o privire la Railscasts din secțiunea Resurse suplimentare din partea de jos a lecției pentru a afla mai multe despre beneficiile API-ului.

Concluzie

Vom lucra mai îndeaproape cu aplicația dvs. ca API în timpul cursului Javascript. În acest curs, veți crea mai multe aplicații full-stack care utilizează apeluri AJAX pentru o experiență mai bună a utilizatorului, care implică în esență redarea datelor XML sau JSON în loc de o pagină HTML completă. Veți crea apoi mai multe aplicații Javascript cu o singură pagină care se bazează pe API-ul furnizat de aplicația dvs. Rails pentru a prelua toate datele necesare din baza de date, dar, în caz contrar, rulează pe partea client (în browser).

Cel mai bun mod de a înțelege un API este să creați și să interacționați cu el, pe care ne vom concentra în proiectele noastre.

, funcții, structuri și constante furnizate de o aplicație (bibliotecă, serviciu) sau sistem de operare pentru utilizare în produse software externe. Folosit de programatori atunci când scriu tot felul de aplicații.

YouTube enciclopedic

• 1 / 5

  API-ul definește funcționalitatea pe care programul (modul, bibliotecă) o oferă, în timp ce API-ul vă permite să faceți abstracție de la modul exact în care este implementată această funcționalitate.

  Dacă un program (modul, bibliotecă) este considerat o cutie neagră, atunci API-ul este un set de „mânere” care sunt disponibile utilizatorului acestei casete și pe care acesta le poate învârti și trage.

  Componentele software interacționează între ele prin intermediul API-urilor. În acest caz, componentele formează de obicei o ierarhie - componentele de nivel înalt folosesc API-ul componentelor de nivel scăzut și, la rândul lor, folosesc API-ul componentelor de nivel inferior.

  Protocoalele de transfer de date prin Internet sunt construite pe acest principiu. Stiva de protocol standard (model de rețea OSI) conține 7 straturi (de la stratul de transfer fizic de biți la nivelul de protocol de aplicație, cum ar fi HTTP și IMAP). Fiecare strat folosește funcționalitatea stratului de transfer de date anterior („inferior”) și, la rândul său, oferă funcționalitatea necesară la nivelul următor („superior”).

  Este important de reținut că conceptul de protocol este apropiat ca înțeles de conceptul de API. Ambele sunt abstracții ale funcționalității, doar că în primul caz vorbim de transfer de date, iar în al doilea vorbim despre interacțiunea aplicațiilor.

  API-ul bibliotecii de funcții și clase include o descriere semnăturiȘi semantica functiilor.

  Semnătura funcției

  Uneori se disting semnătură de apelȘi semnătură de implementare funcții. O semnătură de apel este de obicei compilată din structura sintactică a unui apel de funcție, ținând cont de semnătura domeniului de aplicare al funcției date, numele funcției, secvența de tipuri reale de argumente din apel și tipul de rezultat. Semnătura de implementare include de obicei câteva elemente din structura sintactică a declarației funcției: un specificator al domeniului funcției, numele acesteia și o secvență de tipuri de argumente formale.

  De exemplu, în limbajul de programare C++, o funcție simplă este identificată în mod unic de către compilator prin numele și secvența de tipuri a argumentelor sale, care constituie semnătura funcției în acest limbaj. Dacă o funcție este o metodă a unei anumite clase, atunci și numele clasei va fi inclus în semnătură.

  În industria software, API-urile obișnuite, standard, pentru funcționalitatea standard sunt importante, deoarece asigură că toate programele care folosesc un API comun vor funcționa la fel de bine, sau cel puțin într-o manieră obișnuită familiară. În cazul API-urilor GUI, aceasta înseamnă că programele vor avea o interfață de utilizator similară, ceea ce face mai ușor să învețe noi produse software.

  Pe de altă parte, diferențele dintre API-urile diferitelor sisteme de operare fac foarte dificilă portarea aplicațiilor între platforme. Există diverse metode de a ocoli această complexitate - scrierea de API-uri „intermediare” (wxWidgets, , GTK etc. API-uri GUI), scrierea de biblioteci care mapează apelurile de sistem ale unui sistem de operare la apelurile de sistem ale altui sistem de operare (execuții precum Wine, cygwin etc. .), introducerea standardelor de codare în limbaje de programare (de exemplu, biblioteca standard a limbajului C), scrierea limbajelor interpretate implementate pe diferite platforme (python, perl, php, tcl, Java etc.).

  De asemenea, trebuie remarcat faptul că programatorul are adesea la dispoziție mai multe API-uri diferite pentru a obține același rezultat. Mai mult, fiecare API este de obicei implementat folosind componente software API de un nivel inferior de abstractizare.

  De exemplu: pentru a vedea linia „Hello, world!” în browser. ", trebuie doar să creați un document HTML cu un titlu minim și un corp simplu care să conțină această linie. Când browserul deschide acest document, programul browser va transmite numele fișierului (sau un descriptor de fișier deja deschis) bibliotecii care procesează documentele HTML, care, la rândul său, folosind API-ul sistemului de operare, va citi acest fișier și va înțelege structura acestuia. , apoi apelați secvențial prin biblioteca API a operațiunilor standard de primitive grafice, cum ar fi „șterge fereastra”, „scrieți „Bună, lume!” în fontul selectat”. În timpul efectuării acestor operațiuni, biblioteca de primitive grafice va contacta biblioteca interfeței ferestrei cu solicitările corespunzătoare, iar această bibliotecă va apela API-ul sistemului de operare pentru a scrie date în memoria tampon a plăcii video.

  Mai mult, la aproape fiecare nivel există de fapt mai multe API-uri alternative posibile. De exemplu: am putea scrie documentul sursă nu în HTML, ci în LaTeX și am putea folosi orice browser pentru afișare. Diferitele browsere folosesc în general biblioteci HTML diferite și, în plus, totul poate fi compilat folosind diferite biblioteci primitive și pe sisteme de operare diferite.

  Prin urmare, principalele provocări ale sistemelor API pe mai multe niveluri existente sunt:

  • Dificultate în portarea codului programului de la un sistem API la altul (de exemplu, la schimbarea sistemului de operare);
  • Pierderea funcționalității la trecerea de la un nivel inferior la unul superior. În linii mari, fiecare „layer” API este creat pentru a facilita execuția unui set standard de operațiuni. Dar, în același timp, devine cu adevărat dificil sau devine fundamental imposibil să efectuați alte operațiuni care sunt furnizate de un nivel inferior de API.

  Cele mai cunoscute API-uri

  Sisteme de operare

  Este timpul să vorbim despre un astfel de concept ca Funcțiile API în limbajul Visual Basic. De ce sunt importante aceste funcții în Visual Basic? Să ne dăm seama, în primul rând, când începeți să programați în Visual Basic, veți înțelege imediat că folosind aceste funcții puteți scrie programe foarte serioase și, în al doilea rând, pur și simplu nu puteți face mare lucru fără a utiliza funcții API, de exemplu, aproape tot ce este legat de utilizarea sistemul de operare Windows ( de exemplu: aflați numele de utilizator, spațiul pe hard disk etc.).

  Dar pentru a începe să puneți aceste funcții în practică, trebuie să știți care sunt ele, să vorbim mai întâi despre asta.

  Teorie asupra funcțiilor API Visual Basic

  API este o abreviere pentru Application Programming Interface ( interfața de programare a aplicației). Cu alte cuvinte, un API este un set de funcții pe care sistemul de operare însuși le oferă programatorului să le folosească în programele lor. Folosind API-ul, programatorii își pot pune cu ușurință ideile în practică.

  Funcțiile API pot fi apelate din Visual Basic pentru a efectua sarcini pentru care codul standard Visual Basic nu este suficient. De exemplu, instrumentele standard Visual Basic nu vă permit să închideți computerul sau să-l reporniți. Cu toate acestea, toate acestea pot fi făcute cu ușurință apelând funcția API corespunzătoare.

  Aproape toate funcțiile care se află în Windows sunt situate în interiorul DLL-urilor ( Biblioteca de linkuri dinamice). Toate fișierele dll se află în folderul de sistem Windows. Există peste 1.000 de funcții API, care se încadrează în patru categorii principale.

  • Lucrul cu aplicații - lansarea și închiderea aplicațiilor, procesarea comenzilor din meniu, mutarea și redimensionarea ferestrelor;
  • Grafică - crearea de imagini;
  • Informații de sistem - identificarea discului curent, dimensiunea memoriei, numele utilizatorului curent etc.;
  • Lucrul cu registrul - manipularea registrului Windows.

  Utilizarea funcțiilor API în practică

  Acum să trecem la utilizarea acestor funcții în practică. Funcțiile API apelate în Visual Basic trebuie mai întâi declarate. Declarația specifică numele DLL-ului și funcției, precum și informații despre numărul și tipul de argumente.

  Procedurile DLL sunt declarate cu comanda Declarare în secțiunea Declarații generale a unui modul de formular sau a unui modul standard:

  Declarați numele funcției Lib "biblioteca" [[([ _ variabilă [,ByVal,] variabilă ]...])] Ca tip

  Procedurile DLL găsite în modulele standard sunt publice în mod implicit și pot fi apelate de oriunde în aplicație. Procedurile declarate într-un modul de formular sunt private și trebuie să fie precedate de cuvântul cheie Privat.

  Secțiunea Lib vă spune unde să căutați fișierul DLL care conține funcția. Când vă referiți la bibliotecile de bază Windows (user32.dll, kernel32.dll, gdi.dll), extensia nu trebuie inclusă.

  Dacă calea fișierului nu este specificată, atunci parcurgerea directorului începe în următoarea secvență

  1. Directorul care conține fișierul EXE al programului;
  2. Directorul curent;
  3. Director de sistem Windows;
  4. Director Windows;
  5. Variabila de mediu cale.

  Iată o mică listă de DLL-uri standard Windows:

  • advapi.dll - protecție NT, registru și alte servicii avansate;
  • comdlg.dll - casete de dialog standard;
  • gdi.dll - interfața dispozitivului grafic;
  • kernel32.dll - memorie, discuri, procese, resurse;
  • mpr.dll - rețele;
  • netapi32.dll - bibliotecă API de rețea;
  • shell32.dll - Windows shell, drag-and-drop, selectie pictograme;
  • user32.dll - interfata utilizator - ferestre, meniuri, linii, mesaje;
  • version.dll - controlul versiunii;
  • winmm.dll - multimedia, sunet, joystick-uri, cronometre;
  • winspoll.dll - manager de imprimare.

  Majoritatea procedurilor DLL sunt documentate folosind notația limbajului de programare C și C++. Pentru a converti cu succes o funcție API într-o comandă Declare, trebuie să înțelegeți mecanismul de transmitere a argumentelor. De obicei, argumentele sunt transmise după valoare. În acest caz, cuvântul cheie ByVal este plasat înaintea numelui argumentului. Dacă argumentul este transmis prin referință, atunci ByRef este setat.

  Iată cea mai mică listă de funcții care sunt utilizate în Visual Basic:

  • BitBlt - copiază o imagine de la un hDC la altul;
  • FindWindow - găsește mânerul unei ferestre cu Legenda specificată;
  • GetCursorPos - returnează poziția curentă a cursorului mouse-ului (la nivel global);
  • GetDriveType - returnează tipul de unitate;
  • GetForegroundWindow - returnează mânerul ferestrei active;
  • SetCursorPos - setează o nouă poziție a cursorului mouse-ului;
  • SetVolumeLabel - schimbă eticheta discului;
  • SetWindowPos - setează poziția unei ferestre cu un anumit Mâner (puteți folosi și această funcție pentru a face fereastra deasupra tuturor celorlalte);
  • ShellExecute - lansează aplicația asociată extensiei care are fișierul specificat (poate și pur și simplu lansa aplicația specificată);
  • ShowCursor - ascunde sau afișează cursorul mouse-ului pe ecran.

  Exemple de lucru cu registrul

  De asemenea, atunci când programați în Visual Basic și în alte limbi, apare o problemă atunci când trebuie să utilizați registrul Windows, dar folosind funcții API acest lucru este ușor de făcut, de exemplu:

  Pentru a citi un parametru șir utilizați funcția GetRegString

  Exemplu:

  Dim test As String test = GetRegString(HKEY_LOCAL_MACHINE, _ "Software\Microsoft\DirectX", "Version") Form1.Caption = test

  Pentru a citi un parametru DWORD GetRegDWord

  Exemplu:

  Dim test As Long test = GetRegDWord(HKEY_LOCAL_MACHINE, _ "Software\Microsoft\Internet Explorer\AboutURLs", "Home") Form1.Caption = test

  Pentru a scrie un parametru șir, utilizați SetRegString

  Exemplu:

  SetRegString HKEY_LOCAL_MACHINE, _ „Software\test”, „MyProgram”, „Options”

  Dacă cheia sau parametrul nu a fost creat, atunci va fi creat dacă cheia sau parametrul există deja, atunci noile valori vor fi scrise peste cele vechi.

  Pentru a scrie un parametru de tip DWORD, utilizați SetRegDWord

  Exemplu:

  SetRegDWord HKEY_LOCAL_MACHINE, _ „Software\test”, „MyProgram”, „555”

  Pentru a elimina o cheie din registry, utilizați funcția DeleteRegKey

  Exemplu:

  DeleteRegKey HKEY_LOCAL_MACHINE, „Software”, „test”, True

  Al doilea parametru - cheia părinte
  Al treilea parametru este True - dacă este necesară confirmarea pentru ștergere sau False - dacă confirmarea nu este necesară.

  Pentru a elimina o valoare din registry, utilizați funcția DeleteRegValue

  Exemplu:

  DeleteRegValue HKEY_LOCAL_MACHINE,_ „Software\Microsoft\Internet Explorer\AboutURLs”, „mozilla”, False

  De fapt, posibilitățile funcțiilor API din sistemul de operare Windows sunt aproape nelimitate. Să terminăm această revizuire a acestei caracteristici Visual Basic și să scriem în sfârșit un mic program folosind funcțiile API.

  Acest program afișează pur și simplu un mesaj pe ecran, lipiți următorul cod:

  Private Declare Funcție BeginPath Lib "gdi32" (ByVal hdc As Long) As Long Private Declare Funcție EndPath Lib "gdi32" (ByVal hdc As Long) As Long Private Declare Funcția PathToRegion Lib "gdi32" (ByVal hdc As Long) As Long Private Declare Funcție SetWindowRgn Lib "user32" (ByVal hWnd As Long, ByVal hRgn As Long, ByVal bRedraw As Boolean) As Long Private Sub Form_Load() Const TEXT = "Ați folosit API-ul" Dim hRgn As Long Font.Name = "Times New Roman " Font.Bold = True Font.Size = 60 Width = TextWidth(TEXT) Height = TextHeight(TEXT) BeginPath hdc Print TEXT EndPath hdc hRgn = PathToRegion(hdc) SetWindowRgn hWnd, hRgn, False Move (Screen.Wid)th 2 , (Screen.Height - Height) / 2 End Sub

  Aici am folosit 4 funcții (BeginPath, EndPath, PathToRegion, SetWindowRgn), care se află în două biblioteci dll (gdi32, user32).

  Asta este tot pentru acum!