Opprette et API-sentrisk webprogram

Planlegger å begynne å jobbe med et nytt webprogram? I denne opplæringen diskuterer vi hvordan du lager et API-sentrisk webprogram, og forklar hvorfor dette er viktig i dagens multiplattformsverden.

Ser etter en snarvei?

Hvis du vil ha en rask løsning, sjekk ut en av API-elementene på Envato Market, for eksempel API Framework, som lar deg lage din egen API på et blunk. Rammen er veldig enkel å bruke og utvide hvis du har PHP og OOP kunnskap.

API Framework

Eller du kan prøve API-en til HTML med PHP-tjenesten på Envato Studio. Hvis du bestiller denne tjenesten, kan du analysere noen API fra tredjeparts nettsteder og vise resultatene på ditt eget nettsted, med layout og funksjoner.

Introduksjon

API?

For de som ikke er kjent med begrepet, er API kort for Applikasjonsprogrammeringsgrensesnitt. Ifølge Wikipedia:

Et applikasjonsprogrammeringsgrensesnitt (API) er en kildekodenbasert spesifikasjon som skal brukes som et grensesnitt av programvarekomponenter for å kommunisere med hverandre. En API kan inneholde spesifikasjoner for rutiner, datastrukturer, objektklasser og variabler.

API Visualisering
Bilde med lov av http://blog.zoho.com

I enklere termer refererer en API til et sett med funksjoner som er bygd inn i et program, som kan brukes av andre applikasjoner (eller i seg selv, som vi ser senere), for å samhandle med applikasjonen. En API er en fin måte å eksponere programmets funksjonalitet for eksterne applikasjoner på trygt og sikkert, siden all funksjonalitet som disse eksterne applikasjonene kan gjøre er begrenset med hvilken funksjonalitet som er utsatt i API.

Hva er en "API-sentrisk" webapplikasjon?

En API-sentrisk webapplikasjon er et webprogram som i utgangspunktet utfører de fleste, om ikke, all funksjonalitet gjennom API-anrop.

en API-sentrisk webapplikasjon er et webprogram som i utgangspunktet utfører de fleste, om ikke alle dets funksjonalitet gjennom API-anrop. Hvis du for eksempel skulle logge på en bruker, ville du sende hans legitimasjon til API-en, og API-en ville gi deg et resultat som sier om brukeren oppgav riktig bruker-passord kombinasjon.

En annen egenskap ved API-sentrisk webapplikasjon er at API-en alltid vil være statsløs, noe som betyr at den ikke kan gjenkjenne API-anrop etter økt. Siden API-anrop vil bli laget av vanligvis via backend-koden, vil det være vanskelig å implementere økthåndtering, siden det vanligvis ikke er noen cookies involvert i det. Denne begrensningen er faktisk bra - dette "tvinger" en utvikler til å bygge en API som fungerer ikke basert på den nåværende brukerens tilstand, men heller på funksjonalitet, noe som igjen gjør det lettere å teste, siden den nåværende tilstanden til en bruker trenger ikke å bli gjenopprettet.

Hvorfor gå gjennom all denne trøbbel?

Som webutviklere har vi sett teknologi utvikle førstehånds. Det er allment kjent at folk i dag ikke bare bruker programmer via en nettleser, men via andre gadgets, som mobiltelefoner og nettbrett. For eksempel, denne artikkelen om Mashable, med tittelen "Forbrukere bruker nå mer tid på mobile apper enn nettet", sier:

Forbrukerne bruker mer tid på mobilapper enn på nettet for første gang, hevder en ny rapport.

Flurry sammenlignet sine mobildata med statistikk fra comScore og Alexa, og fant at i juni brukte forbrukerne 81 minutter per dag ved hjelp av mobile apps, sammenlignet med 74 minutter med nett surfing.

Her er en nyere artikkel fra ReadWriteWeb, med tittelen "More People Browse On Mobile Than Use IE6 & IE7 Kombinert:

De nyeste dataene om nettlesertrender fra Sitepoint viser at flere personer surfer på nettet på smarttelefoner enn å bruke Internet Explorer 6 og 7 kombinert. Disse to gamle clunkers har vært bugbears av webutviklere i mange år, noe som krever at nettsteder nedbrytes så pent som mulig til den minste fellesnevneren av nettlesere. Men det er en ny verden nå; 6,95% av nettaktiviteten i november 2011 var på mobilnettlesere, og bare 6,49% var på IE 6 eller 7.

Som vi tydeligvis kan se, får flere og flere personer sine nyheter fra alternative arenaer, spesielt mobile enheter.

Hva har dette å gjøre med meg å lage et API-sentrisk webprogram?

Dette vil uunngåelig føre til mer bruk av vår søknad, siden den kan brukes hvor som helst en person ønsker.

En av hovedfordelene ved å lage en API-sentrisk applikasjon er at den hjelper deg med å bygge opp funksjonalitet som kan brukes av NOEN Enhet, det være seg en nettleser, en mobiltelefon, en nettbrett eller en desktop-app. Alt du trenger å gjøre er å lage API på en slik måte at alle disse enhetene kan kommunisere med det, og voila! Du har bygget et sentralisert program som kan ta inn og utføre funksjonalitet fra en hvilken som helst enhet som en person har!

API-sentrisk applikasjonsdiagram

Ved å lage en applikasjon på denne måten, kan vi enkelt dra nytte av de ulike mediumene som brukes av forskjellige personer. Dette vil uunngåelig føre til mer bruk av en søknad, siden den kan brukes hvor som helst en person ønsker.

For å kjøre poenget hjemme, her er en artikkel om Twitters nye redesignede nettside, som forteller oss om hvordan de nå bruker API-en til å drive Twitter.com, og gjør det i hovedsak API-sentrert:

En av de viktigste arkitektoniske endringene er at Twitter.com nå er klient av vår egen API. Den henter data fra de samme sluttpunktene som mobilnettstedet, våre apper for iPhone, iPad, Android og alle tredjeparts applikasjoner bruker. Dette skiftet tillot oss å tildele flere ressurser til API-teamet, og generere over 40 oppdateringer. I den innledende sidebelastningen og hver samtale fra klienten hentes alle data fra en svært optimalisert JSON-fragmentbufferen.

I denne opplæringen lager vi et enkelt TODO-listeprogram som er API-sentrisk og oppretter en frontend-klient i nettleseren som samhandler med TODO-listeapplikasjonen. På slutten vil du kjenne de integrerte delene av et API-sentrisk program, og samtidig legge til rette for sikker kommunikasjon mellom de to. Med det i tankene, la oss begynne!

Trinn 1: Planlegg programmets funksjoner

TODO-programmet vi skal bygge i denne opplæringen, vil ha de grunnleggende CRUD-funksjonene:

Skape TODO elementer
Lese TODO elementer
Oppdater TODO Elementer (endre navn, merk som ferdig, markere som fortrykt)
Slett TODO elementer

Hver TODO-gjenstand vil ha:

en Tittel
en Forfallsdato
en Beskrivelse
et flagg for å fortelle om TODO-elementet Er ferdig

La oss mockup programmet også, så vi har en veiledning om hvordan det skal se ut etterpå:

Trinn 2: Opprett API-serveren

Siden vi utvikler et API-sentrisk program, oppretter vi to "prosjekter": API Server, og Front-end Client. La oss begynne med å opprette API-serveren først.

På webserverens mappe, opprett en mappe som heter simpletodo_api, og opprett en index.php fil. Dette index.php filen vil fungere som en frontkontrollen for API, så alle forespørsler til API-serveren vil bli gjort gjennom denne filen. Åpne den og legg inn følgende kode innvendig:

$ Handling (); $ resultat ['suksess'] = true;  fangst (Unntak $ e) // fange eventuelle unntak og rapporter problemet $ result = array (); $ resultat ['suksess'] = false; $ resultat ['errormsg'] = $ e-> getMessage ();  // ekko resultatet av API-samtalen echo json_encode ($ result); exit();

Det vi har bygget hovedsakelig her, er en enkel frontkontroller som gjør følgende:

Godta et API-anrop med et hvilket som helst antall parametere
Trekk ut Controller og Handling for API-anropet
Gjør de nødvendige kontrollene for å sikre at Controller og Handling eksistere
Utfør API-anropet
Fangstfeil, hvis noen
Send tilbake et resultat til den som ringer

Ved siden av index.php fil, opprett tre mapper: a kontrollere, modeller og data mappe.

De kontrollere mappen inneholder alle kontrollerne vi skal bruke til API-serveren. Vi bygger den ved hjelp av MVC-arkitekturen for å gjøre strukturen til API-serveren renere og mer organisert.
De modeller mappen inneholder alle datamodellene for API-serveren.
De data mappen vil være hvor API-serveren lagrer data

Gå inn i kontrollermappen og opprett en fil som heter Todo.php. Dette vil være vår kontroller for eventuelle TODO-listelaterte oppgaver. Med funksjonene vi trenger for vår TODO-applikasjon, husk å lage de nødvendige metodene for Todo-kontrolleren:

_params = $ params;  offentlig funksjon createAction () // lage et nytt todo element offentlig funksjon readAction () // les alle todo elementene offentlig funksjon updateAction () // oppdatere et todo element offentlig funksjon deleteAction () // slette et todo-element

Nå legg til nødvendig funksjonalitet for hver handling. Jeg vil gi koden for createAction metode, og jeg lar deg opprette koden for de andre metodene. Hvis du ikke er i humøret, kan du bare laste ned kildekoden for demoen og kopiere den derfra.

offentlig funksjon createAction () // lage et nytt todo-element $ todo = nytt TodoItem (); $ todo-> title = $ this -> _ params ['title']; $ todo-> description = $ this -> _ params ['description']; $ todo-> due_date = $ this -> _ params ['due_date']; $ todo-> is_done = 'false'; // pass brukerens brukernavn og passord for å autentisere brukeren $ todo-> save ($ this -> _ params ['brukernavn'], $ dette -> _ params ['userpass']); // returnere todo-elementet i arrayformat returnere $ todo-> toArray ();

Skape TodoItem.php inne i modeller mappe, slik at vi kan opprette "elementet" -koden. Vær oppmerksom på at jeg ikke vil koble til en database, men jeg vil lagre informasjonen i filer. Det skal være relativt enkelt, men å gjøre dette arbeidet med en hvilken som helst database.

todo_id) || ! is_numeric ($ this-> todo_id)) // todo id er den nåværende tiden $ this-> todo_id = time ();  // få array-versjonen av dette todo-elementet $ todo_item_array = $ this-> toArray (); // lagre seriellisert array-versjonen i en fil $ success = file_put_contents (DATA_PATH. "/ $ userhash / $ this-> todo_id .txt", serialiser ($ todo_item_array)); // Hvis lagringen ikke var vellykket, kast et unntak hvis ($ suksess === falskt) kaste ny unntak ('Kunne ikke lagre todo-elementet');  // returnere array-versjonen returnere $ todo_item_array;  offentlig funksjon tilArray () // returnere en array-versjon av todo-elementet returneringsarrangementet ('todo_id' => $ this-> todo_id, 'title' => $ this-> tittel, 'beskrivelse' => $ this- > beskrivelse, 'due_date' => $ this-> due_date, 'is_done' => $ this-> is_done);

De createAction Metoden kaller to funksjoner på TodoItem modell:

lagre() - dette sparer TodoItem inn i en fil, samt sette todo_id for TodoItem hvis nødvendig
toArray () - Dette returnerer en array versjon av TodoItem, hvor variablene er arrayets indekser

Siden API-en kalles via HTTP-forespørsler, la oss teste det API-anropet ved å ringe det gjennom nettleseren:

http: // localhost / simpletodo_api / controller = todo & action = skape & title = test% 20title & description = test% 20description & DUE_DATE = 12/08/2011 & username = nikko & Userpass = test1234

Hvis alt virket, bør du se en ny mappe inne i data mappe og i den mappen, bør du se en fil med følgende innhold:

createAction () resultat

Gratulerer! Du har vellykket opprettet en API-server og laget en API-samtale!

Trinn 3: Sikre API-serveren med en `APP ID` og `APP SECRET`

For øyeblikket er API-serveren innstilt for å akseptere ALLE API-forespørsler. Vi må begrense det til våre egne applikasjoner for å sikre at bare våre egne front-end-klienter kan lage API-forespørsler. Alternativt kan du faktisk lage et system hvor brukere kan lage egne applikasjoner som har tilgang til API-serveren din, ligner på hvordan Facebook og Twitter-applikasjoner fungerer.

Begynn med å opprette et sett med id-nøkkelpar for klientene som skal bruke API-serveren. Siden dette bare er en demo, kan vi bruke en tilfeldig, 32 tegnstreng. For APP ID, la oss si det er søknad APP001.

Åpne index.php filen igjen, og oppdater deretter den med følgende kode:

 '28e336ac6c9423d946ba02d19c6a2632', // tilfeldig generert appnøkkel); // inkluderer våre modeller include_once 'models / TodoItem.php'; // vikle hele greia i en prøvefelt blokk for å ta noen farverdige unntak! prøv // * OPPDATERT * // få kryptert forespørsel $ enc_request = $ _REQUEST ['enc_request']; // få oppgitt app id $ app_id = $ _REQUEST ['app_id']; // sjekk først hvis app-id eksisterer i listen over applikasjoner hvis (! isset ($ applications [$ app_id])) kaste ny unntak ('Program eksisterer ikke!');  // dekrypter forespørselen $ params = json_decode (trim (mcrypt_decrypt (MCRYPT_RIJNDAEL_256, $ applikasjoner [$ app_id], base64_decode ($ enc_request), MCRYPT_MODE_ECB))); // Sjekk om forespørselen er gyldig ved å sjekke om det er en matrise og se etter kontrolleren og handlingen hvis ($ params == false || isset ($ params-> kontroller) == false || isset ($ params-> handling ) == false) Kast ny unntak ('Forespørsel er ikke gyldig');  // cast det inn i en array $ params = (array) $ params; ...

Det vi har gjort her, implementerer faktisk en veldig enkel måte å godkjenne våre front-end-klienter ved hjelp av et system som ligner på offentlig-privat nøkkelautentisering. I utgangspunktet er her en trinnvis sammenstilling av hvordan autentiseringen skjer:

Offentlig nøkkel kryptering

Et API-anrop er gjort, i det en $ APP_ID og $ enc_request er gitt.
de $ enc_request verdien er API-anropsparametrene, kryptert med APP KEY. De APP KEY er ALDRI Sendt til serveren, er det bare brukt til å hash forespørselen. I tillegg kan forespørselen bare dekrypteres ved hjelp av APP KEY.
Når API-anropet kommer til API-serveren, vil det sjekke sin egen liste over applikasjoner for APP ID sørget for
Når det er funnet, forsøker API-serveren å dekryptere forespørselen ved å bruke nøkkelen som samsvarer med APP ID sendt
hvis det var vellykket å dekryptere det, fortsett deretter med programmet

Nå som API-serveren er sikret med en APP ID og APP SECRET, Vi kan begynne å programmere en front-end klient for å bruke API-serveren.

Trinn 4: Lag nettleserens frontend-klient

Vi starter med å sette opp en ny mappe for front-end-klienten. Opprett en mappe som heter simpletodo_client_browser på webserverens mappe. Når det er gjort, opprett en index.php-fil og sett denne koden inne:

   SimpleTODO           SimpleTODO 
 
 
     Brukernavn:  Passord:

Det skulle se slik ut:

SimpleTODO Login Page

Legg merke til at jeg har tatt med 2 JavaScript-filer og 2 CSS-filer her:

reset.css er ditt standard CSS reset script. Jeg bruker meyerweb.com css reset.
bootstrap.min.css er Twitter Bootstrap
jquery.min.js er det siste jQuery-biblioteket
jquery-ui-1.8.16.custom.min.js er det siste jQuery UI-biblioteket

Neste, la oss lage login.php fil så lagrer vi brukernavnet og passordet i en økt på klienten.

 Her starter vi bare en økt for brukeren, basert på brukernavnet og passordkombinasjonen som brukeren vil gi. Dette fungerer som en enkel kombinasjonsnøkkel, som tillater en bruker å få tilgang til lagrede TODO-elementer for en bestemt kombinasjon av både brukernavn og passord. Vi viderekobler til todo.php, hvor vi begynner å samhandle med API-serveren. Før vi starter kodingen av todo.php fil skjønt, la oss først opprette en ApiCaller klassen, som vil inkapslere alle API-anropsmetoder vi trenger, inkludert kryptering av forespørslene.
 Skape apicaller.php og legg inn følgende:
 _app_id = $ app_id; $ dette -> _ app_key = $ app_key; $ dette -> _ api_url = $ api_url;  // send forespørselen til API-serveren // også krypterer forespørselen, deretter sjekker // hvis resultatene er gyldige offentlige funksjon sendRequest ($ request_params) // krypter forespørselsparametrene $ enc_request = base64_encode (mcrypt_encrypt (MCRYPT_RIJNDAEL_256, $ dette -> _ app_key, json_encode ($ request_params), MCRYPT_MODE_ECB)); // lage parameter-arrayet, som vil // være POST-parametrene $ params = array (); $ params ['enc_request'] = $ enc_request; $ params ['app_id'] = $ dette -> _ app_id; // initialisere og sette opp krøllehandleren $ ch = curl_init (); curl_setopt ($ ch, CURLOPT_URL, $ this -> _ api_url); curl_setopt ($ ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt ($ ch, CURLOPT_POST, telle ($ params)); curl_setopt ($ ch, CURLOPT_POSTFIELDS, $ params); // utfør forespørselen $ result = curl_exec ($ ch); // json_dekode resultatet $ result = @json_decode ($ result); // sjekk om vi kan json_dekode resultatet riktig hvis ($ result == false || isset ($ result ['success']) == false) kaste ny unntak ('Forespørsel var ikke riktig');  // hvis det oppstod en feil i forespørselen, kast et unntak dersom ($ result ['success'] == false) kaste ny unntak ($ result ['errormsg']);  // hvis alt gikk bra, returner data retur $ resultat ['data']; 
 Vi skal bruke ApiCaller klasse for å sende forespørsler til vår API-server. På denne måten vil all nødvendig kryptering og cURL initialiseringskode være på ett sted, og vi må ikke gjenta koden vår.
   de __construct funksjonen tar i bruk tre parametere:   $ APP_ID - de APP ID for klienten (som er APP001 for nettleserklienten)
  $ app_key - de APP KEY for klienten (som er 28e336ac6c9423d946ba02d19c6a2632 for nettleserklienten)
  $ api_url - URL-adressen til API-serveren, som er http: // localhost / simpletodo_api / 
 
 
  de Send forespørsel() funksjon:  krypterer forespørselsparametrene ved hjelp av mcrypt bibliotek på samme måte som API-serveren dekrypterer det
 genererer $ _POST parametere som skal sendes til API-serveren
 kjører API-anropet via cURL 
 sjekker resultatet av API-anropet var vellykket eller ikke
 returnerer dataene når alt gikk i henhold til planen
 
 
 
 La oss begynne med todo.php side. Først av, la oss lage noen kode for å hente den nåværende listen over todo-elementer for brukeren nikko med passordet test1234 (dette er bruker- / passordkombinasjonen vi brukte tidligere for å teste API-serveren).
 sendRequest (array ('controller' => 'todo', 'action' => 'read', 'brukernavn' => $ _SESSION ['brukernavn'], 'userpass' => $ _SESSION ['brukerpass'])); ekko "; var_dump ($ todo_items);
 Gå til index.php side, logg inn som Nikko / test1234, og du bør se en var_dump () av TODO-elementet vi opprettet tidligere.
    Gratulerer, du har vellykket gjort et API-anrop til API-serveren! I denne koden har vi:
  startet sesjonen slik at vi har tilgang til brukernavn og Userpass i $ _SESSION 
 instantiated en ny ApiCaller klasse, gir den APP ID, APP KEY og nettadressen til API-serveren
 send en forespørsel via Send forespørsel() metode
 
 Nå, la oss reformatere dataene slik at det ser bedre ut. Legg til følgende HTML for todo.php kode. Ikke glem å fjerne var_dump ()!
    SimpleTODO             SimpleTODO 
 
 
   Opprett et nytt TODO-element   Tittel:
 Forfallsdato:
 Beskrivelse:
   
 
 
 
   tittel; ?>
    todo_id; ?> "> Slett 
  Forfallsdato:
 Beskrivelse:
<?php echo $todo->beskrivelse; ?>
 
  is_done == 'false'):?>          
 
 
  
 
  
 Det burde nå se slik ut:
    Ganske kul, huh? Men dette gjør for øyeblikket ingenting, så la oss begynne å legge til noen funksjonalitet. Jeg vil gi koden for new_todo.php, som vil ringe til todo / opprette API-anrop for å opprette et nytt TODO-element. Opprette de andre sidene (update_todo.php og delete_todo.php) burde være veldig lik denne, så jeg lar det opp til deg å lage dem. Åpne opp new_todo.php og legg til følgende kode:
 sendRequest (array ('controller' => 'todo', 'action' => 'opprett', 'title' => $ _POST ['title'], 'due_date' => $ _POST ['due_date'] '=> $ _POST [' beskrivelse '],' brukernavn '=> $ _SESSION [' brukernavn '],' userpass '=> $ _SESSION [' brukerpass '])); header ('Location: todo.php'); exit(); ?>
 Som du kan se, er new_todo.php side bruker ApiCaller igjen for å lette sendingen av todo / opprette forespørsel til API-serveren. Dette gjør i utgangspunktet det samme som før:
  start en økt så den har tilgang til $ brukernavn og $ Userpass lagret i $ _SESSION 
 Installer en ny ApiCaller klasse, gir den APP ID, APP KEY og nettadressen til API-serveren
 send forespørselen via Send forespørsel() metode
 omdirigere tilbake til todo.php 
 
    Gratulerer, det fungerer! Du har opprettet et API-sentrisk program!
 
 Konklusjon
 Det er så mange fordeler med å utvikle et program som er bygget rundt en API. Vil du opprette en Android-applikasjonsversjon av SimpleTODO? All funksjonalitet du trenger, er allerede på API-serveren, så alt du trenger å gjøre er bare å opprette klienten! Vil du refactor eller optimalisere noen av klassene? Ikke noe problem - bare sørg for at utgangen er den samme. Trenger du å legge til flere funksjoner? Du kan gjøre det uten å påvirke noen av klientens kode!
 Selv om det er noen ulemper som lengre utviklingstider eller mer kompleksitet, har fordelene ved å utvikle en webapplikasjon på denne måte stor uvekt ulemper. Det er opp til oss å utnytte denne typen utvikling i dag, så vi kan høste fordelene senere.
 !



		
			
	   
	




Kode