Mikä on sovellusliittymä? Englanniksi Kiitos.

Ennen kuin opin ohjelmistokehityksen, API kuulosti eräänlaiselta oluelta.

Tänään käytän termiä niin usein, että olen itse asiassa äskettäin yrittänyt tilata API: n baarista.

Baarimikon vastaus oli heittää 404: resurssia ei löydy.

Tapaan paljon ihmisiä, jotka työskentelevät sekä tekniikassa että muualla, joilla on melko epämääräinen tai väärä käsitys siitä, mitä tämä melko yleinen termi tarkoittaa.

Teknisesti API tarkoittaa lyhenne sanoista Application Programming Interface . Jossakin vaiheessa tai toisessa suurin osa suurista yrityksistä on rakentanut sovellusliittymiä asiakkailleen tai sisäiseen käyttöön.

Mutta miten selität API: n yksinkertaisella englannilla? Ja onko olemassa laajempaa merkitystä kuin mitä käytetään kehityksessä ja liiketoiminnassa? Ensinnäkin, vedetään takaisin ja katsotaan, miten verkko itse toimii.

WWW ja etäpalvelimet

Kun ajattelen verkkoa, kuvittelen suuren verkkoon yhdistettyjä palvelimia.

Jokainen Internet-sivu on tallennettu jonnekin etäpalvelimelle. Etäpalvelin ei ole loppujen lopuksi niin mystinen - se on vain osa etätietokoneesta, joka on optimoitu käsittelemään pyyntöjä.

Jotta asiat näkyisivät, voit käynnistää kannettavan tietokoneen palvelimen, joka pystyy palvelemaan koko verkkosivustoa verkossa (itse asiassa insinöörit käyttävät paikallista palvelinta verkkosivustojen kehittämiseen ennen niiden julkaisemista yleisölle).

Kun kirjoitat selaimeesi www.facebook.com, pyyntö lähetetään Facebookin etäpalvelimelle. Kun selaimesi saa vastauksen, se tulkitsee koodin ja näyttää sivun.

Selaimelle, joka tunnetaan myös nimellä asiakas , Facebookin palvelin on API. Tämä tarkoittaa, että aina kun vierailet verkkosivulla, olet vuorovaikutuksessa jonkin etäpalvelimen sovellusliittymän kanssa.

API ei ole sama kuin etäpalvelin - pikemminkin se on palvelimen osa, joka vastaanottaa pyyntöjä ja lähettää vastauksia .

API: t tapa palvella asiakkaitasi

Olet luultavasti kuullut yrityksistä, jotka pakkaavat API: ita tuotteina. Esimerkiksi Weather Underground myy pääsyn säätietojen sovellusliittymäänsä.

Esimerkkiskenaario: Pienyrityksesi verkkosivustolla on lomake, jota käytetään asiakkaiden rekisteröimiseen tapaamisiin. Haluat antaa asiakkaillesi mahdollisuuden luoda automaattisesti Google-kalenteritapahtuma kyseisen tapaamisen yksityiskohdilla.

API-käyttö: Ajatuksena on, että verkkosivustosi palvelin puhuu suoraan Googlen palvelimelle pyytämällä luomaan tapahtuma annetuilla tiedoilla. Palvelimesi vastaanottaisi Googlen vastauksen, käsitteli sen ja lähetti asiaankuuluvat tiedot selaimelle, kuten vahvistusviestin käyttäjälle.

Vaihtoehtoisesti selaimesi voi usein lähettää API-pyynnön suoraan Googlen palvelimelle ohittaen palvelimesi.

Kuinka tämä Google-kalenterin sovellusliittymä eroaa minkä tahansa muun etäpalvelimen sovellusliittymästä?

Teknisesti ero on pyynnön ja vastauksen muoto.

Koko verkkosivun hahmontamiseksi selaimesi odottaa vastausta HTML-muodossa, joka sisältää esityskoodin, kun taas Google-kalenterin API-kutsu vain palauttaisi tiedot - todennäköisesti muodossa, kuten JSON .

Jos verkkosivustosi palvelin tekee API-pyynnön, verkkosivustosi palvelin on asiakas (samanlainen kuin selaimesi asiakas, kun käytät sitä verkkosivustolle siirtymiseen).

Käyttäjien näkökulmasta sovellusliittymien avulla he voivat suorittaa toiminnon poistumatta verkkosivustoltasi.

Useimmat modernit verkkosivustot kuluttavat ainakin joitain kolmannen osapuolen sovellusliittymiä.

Monilla ongelmilla on jo kolmannen osapuolen ratkaisu, joko kirjaston tai palvelun muodossa. Olemassa olevan ratkaisun käyttö on usein vain helpompaa ja luotettavampaa.

Ei ole harvinaista, että kehitystiimit jakavat sovelluksensa useisiin palvelimiin, jotka keskustelevat keskenään API: n kautta. Palvelimia, jotka suorittavat aputoimintoja pääsovelluspalvelimelle, kutsutaan yleisesti mikropalveluiksi .

Yhteenvetona voidaan todeta, että kun yritys tarjoaa sovellusliittymän asiakkailleen, se tarkoittaa vain sitä, että he ovat rakentaneet joukon omistettuja URL-osoitteita, jotka palauttavat puhtaat tietovastaukset - eli vastaukset eivät sisällä sellaisia ​​esityskustannuksia, joita voit odottaa graafinen käyttöliittymä, kuten verkkosivusto .

Voitko tehdä nämä pyynnöt selaimellasi? Usein kyllä. Koska todellinen HTTP-lähetys tapahtuu tekstinä, selaimesi tekee aina parhaansa vastauksen näyttämiseksi.

Voit esimerkiksi käyttää GitHubin sovellusliittymää suoraan selaimellasi tarvitsematta edes käyttöoikeustunnusta. Tässä on JSON-vastaus, kun vierailet selaimesi GitHub-käyttäjän API-reitillä (//api.github.com/users/petrgazarov):

{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}

Selain näyttää näyttävän onnistuneen näyttämään JSON-vastauksen. Tällainen JSON-vastaus on valmis käytettäväksi koodissasi. Tietoja on helppo poimia tästä tekstistä. Sitten voit tehdä mitä haluat tiedoilla.

A on tarkoitettu sovellukselle

Lopetetaanpa, heitetään vielä muutama esimerkki sovellusliittymistä.

"Sovellus" voi viitata moniin asioihin. Tässä on joitain niistä API: n yhteydessä:

  1. Pala ohjelmistoa, jolla on erillinen toiminto.
  2. Koko palvelin, koko sovellus tai vain pieni osa sovelluksesta.

Periaatteessa mikä tahansa ohjelmisto, joka voidaan erottaa selvästi ympäristöstä, voi olla “A” API: ssa ja todennäköisesti myös jonkinlainen API.

Oletetaan, että käytät koodissasi kolmannen osapuolen kirjastoa. Kun koodi on yhdistetty, kirjastosta tulee osa sovellustasi. Koska erillinen ohjelmisto, kirjastolla olisi todennäköisesti API, jonka avulla se voi olla vuorovaikutuksessa muun koodisi kanssa.

Tässä on toinen esimerkki: Objektisuuntautuneessa suunnittelussa koodi on järjestetty esineiksi. Sovelluksessasi voi olla määritelty satoja esineitä, jotka voivat olla vuorovaikutuksessa toistensa kanssa.

Jokaisella objektilla on API - joukko julkisia menetelmiä ja ominaisuuksia, joita se käyttää vuorovaikutuksessa sovelluksen muiden objektien kanssa.

Kohteella voi olla myös sisäinen logiikka, joka on yksityinen, mikä tarkoittaa sitäpiilotettuulkopuolelta (eikä API: lta).

Toivomme, että otat pois API: n laajemman merkityksen ja tämän päivän yleisimmät käyttötavat.

Mielenkiintoisia resursseja (jutut, jotka jätin pois, mutta jotka ovat silti erittäin hienoja):

Upea YouTube-video DNS: ssä (Domain Name System)

HTTP-protokollan perusteet

Mahtava Khan-akatemian video olio-suunnitteluperiaatteista