Arbetar med RESTful Services i CodeIgniter

CodeIgniter blir välkänt för sin kraft som en PHP-baserad webbapplikationsram, men det är inte ofta att vi ser exempel på att den används för något annat. Idag lär vi oss hur vi kan använda CodeIgniter för att skapa ett RESTful API för dina befintliga webbprogram och visa hur du kan interagera med ditt eget API eller andra RESTfula webbtjänster, som Facebook och Twitter.

Som du kanske vet kan du hitta ett brett urval av CodeIgniter-skript och -program på Envato Market, från medlemsskript till menyfunktioner och mycket mer.

Handledning detaljer

  • Program: CodeIgniter, CodeIgniter REST-server och CodeIgniter REST-klient
  • Svårighet: Medium
  • Beräknad slutförd tid: 30 minuter

Introduktion

Om du har följt CodeIgniter From Scratch serier kommer du att veta att det är relativt snabbt och enkelt att sätta ihop enkla webbapplikationer, som bloggar, CMS-system, broschyrsidor etc. En sak du kanske inte har tänkt på använder CodeIgniter för att skapa ett interaktivt API. Efter att ha försökt flera befintliga REST-implementeringar fann jag att de inte bara saknade enkelhet men saknade de flesta funktioner som du skulle kunna förvänta dig av en RESTful-implementering. så jag byggde min egen. Denna handledning visar dig hur du använder den här koden för att ställa in ditt REST API, och ger exempel på hur man kan interagera med det från din webbapplikation.

antaganden

  1. Du har en webbserver inrättad, lokalt eller online och vet hur man hanterar filer på den.
  2. Du har läst några av CodeIgniter from Scratch tutorials.
  3. Du vet hur du konfigurerar CodeIgniter.
  4. Du vet lite om RESTful tjänster.

Denna handledning är uppdelad i två delar. Vi börjar med att lära oss hur man skapar en RESTful service, sedan längre ner, lär vi oss att interagera med det på några olika sätt.

Del 1 - Skapa ett RESTful API

Steg 1: Konfigurera demo

Först måste du ladda ner codeigniter-restserverkoden från GitHub och extrahera den och flytta koden till din server.

När du öppnar mappen ser du en hel CodeIgniter-installation, som finns där för att driva demo. Detta gör att människor kan spela med REST-demo innan de integreras med din befintliga applikation.

Öppna "Application / config / config.php" och ställ in basen för att få länkar som fungerar. Denna base_url kommer att vara annorlunda för alla och beror helt på var du har laddat upp dina filer.

Steg 2: Webbadresserna

Med de extraherade filerna och base_url är vi redo att ladda upp vår RESTful CodeIgniter-installation och titta på demoen som medföljer den. Bläddra i basadressen, som som standard är:

http: // localhost / restserver

Här hittar du några exempel länkar till example_api controller, som finns på "Application / controllers / example_api.php". Låt oss dissekera URL: erna för dessa exempel för att se vad som händer. Den första webbadressen är en mycket enkel.

Den här URL-adressen ser väldigt ut som vilken annan CodeIgniter-URL som helst med en kontroller och en metod, men i det här diagrammet märks att metoden heter "Resurs". REST handlar om resurser och de är i huvudsak ett substantiv inom din ansökan, som interageras med (dvs. läggs till, raderas, redigeras, frågas) baserat på HTTP-rubriker och URL-frågesträngar eller HTTP-argument.

Standardformatet för utmatning är XML vilket är vad vi ser i det här grundläggande exemplet. De andra länkarna är något större och visar hur parametrarna ska överföras och visa hur utmatningsformatet kan ändras i webbadressen:

Normalt i CodeIgniter passerar du bara parametervärden, men en REST-kontroller accepterar ett antal parametrar i vilken ordning som helst. För att detta ska fungera måste vi passera i namnet på parametern följt av värdet i par.

I slutet av webbadressen är parametern "format". Detta är en reserverad parameter som ändrar utmatningsformat för den begärda data som så:

Genom att ge både API-utvecklaren och klientprogrammet valet av dataformat att använda öppnas API-en till en mycket bredare publik och kan användas med flera programmeringsspråk och system. Dessa tre är inte de enda format som stöds, ur rutan som ditt REST API kan använda:

  • xml - Nästan alla programmeringsspråk kan läsa XML
  • json - användbart för JavaScript och alltmer PHP-appar.
  • csv - öppna med kalkylbladsprogram
  • html - en enkel HTML-tabell
  • php - Representation av PHP-kod som kan vara eval () 'ed
  • serialisera - Serialiserad data som kan vara unserialized i PHP

Medan du lägger till formatet på webbadressen är det inte tekniskt det mest RESTful sättet att ändra format, det möjliggör enkel webbläsartestning och låter utvecklare utan cURL utföra enkla GET-förfrågningar på API. Ju mer RESTful sätt är att skicka en Innehållstyp HTTP-header till REST-styrenheten med cURL, men det kommer att förklaras senare.

Steg 3: Koden

Nu om du öppnar dig application / controllers / example_api.php Du kommer omedelbart att upptäcka några skillnader från normala CodeIgniter controllers.

REST_Controller

I MVC-mönstret är en styrenhet den centrala punkten i logiken. Det kallas när en användare gör en förfrågan och sedan bygger på logiken i styrenheten hämtar den data och matar ut vyer. CodeIgniter innehåller sin egen logik för hur en Controller ska fungera, men när vi gör något annat behöver vi vårt eget REST_Controller-bibliotek för att innehålla sin egen REST-relaterade logik. Så istället för att helt enkelt använda:

 

... du måste använda:

 

Arbeta med resurser

Nu är din tomma kontroller inställd, nästa är metoderna eller "resurser". Detta är förmodligen den mest förvirrande delen av handledningen om du är van vid hur CodeIgniter fungerar. I grund och botten tar du resurs- och HTTP-verben och kombinerar dem för att skapa ett metodnamn. Så de två exemplen vi tittade på hade tidigare en resurs av användare och användare. Eftersom båda dessa laddades i webbläsaren vet vi att det var en GET-förfrågan och så används de två metoderna nedan:

 

Det kan tyckas lite konstigt, men det ger dig möjlighet att använda samma webbadress och svara på begäran beroende på vilket HTTP-verb som har använts. Om någon försöker komma åt ditt API på ett sätt som inte är tillåtet (i det här exemplet PUT eller DELETE) svarar det enkelt med en 404. Om du inte är säker på HTTP-verb, låt mig förklara.

SKAFFA SIG

Används för att hämta information om en befintlig resurs. Detta används av webbläsare när du anger en webbadress och slår go, eller när du klickar på en länk så är den perfekt för att hämta information om en av dina resurser (t.ex. användaren).

POSTA

Används för att uppdatera en befintlig resurs med information. Webbläsare använder detta för att skicka in de flesta typer av blanketter på internet, även om vissa använder GET också genom att skicka in formuläråtgärden med en fråge sträng som innehåller fältdata.

SÄTTA

Mindre vanligt använd och inte stöds av de flesta webbläsare används PUT för att skapa en ny resurs.

RADERA

Används inte heller av många webbläsare, men det här HTTP-verbet används självklart för att radera en resurs.

Om vi ​​lägger in det i kod och tillåter varje verb på resursen användare det skulle se ut så här:

 

Åtkomst till parametrar och returdata

Så nu har API fått sin struktur genom att ange resurserna och definiera en metod för varje HTTP-verb som vi vill stödja. Vi behöver parametrar så att vi kan använda våra CodeIgniter-modeller och bibliotek. Detta är en av de största fördelarna med att använda CodeIgniter för vårt API, eftersom vi kan använda våra befintliga modeller och bibliotek och behöver inte omkoda dem.

få ( 'id')); $ This-> respons ($ data);  funktion user_post () $ data = array ('returnerat:'. $ this-> post ('id')); $ This-> respons ($ data);  funktion user_put () $ data = array ('returnerat:'. $ this-> put ('id')); $ this-> response ($ data; funktion user_delete () $ data = array ('returnerat:'. $ this-> delete ('id')); $ this-> svar ($ data);

Detta exempel innehåller fem nya kodstycken:

$ This-> get ()

Används för att returnera GET-variabler från antingen en söksträng som denna index.php / example_api / user? Id = 1 eller kan ställas in på den mer CodeIgniter'esque sättet med index.php / example_api / user / id / 1.

$ This-> post ()

Är ett alias för $ this-> input-> post () vilket är CodeIgniter-metoden för att få tillgång till $ _POST-variabler med XSS-skydd.

$ This-> sätta ()

Läser i PUT-argument som anges i HTTP-rubrikerna eller via cURL.

$ This-> Delete ()

Du gissade det, det här läser i DELETE-argument, även i HTTP-rubriker eller via cURL.

$ This-> respons ()

Skickar data till webbläsaren i vilket dataformat som begärts, eller som standard till XML. Du kan valfritt skicka en HTTP-statuskod för att visa att den har fungerat eller misslyckats. T.ex. om det angivna IDet inte fanns i databasen, kan du använda $ this-> response (array ('error' => 'User not found.'), 404);

Steg 4: Arbeta med dina modeller

Hittills har vi arbetat med ett exempel API i en ren installation. Så nästa steg är att få ett REST API som körs från din befintliga kodbas.

Även om nedladdningen levereras med en fullständig CodeIgniter-installation för demo och att låta API: er byggas från början, är de enda två filerna av betydelse:

  1. application / config / rest.php
  2. application / bibliotek / REST_Controller.php

Släpp dessa två filer i din CodeIgniter-applikation och skapa en ny API-kontroller.

få ('id')) $ this-> svar (NULL, 400);  $ user = $ this-> user_model-> få ($ this-> get ('id')); om ($ användare) $ this-> response ($ user, 200); // 200 är HTTP-svarskoden annars $ this-> response (NULL, 404);  funktion user_post () $ result = $ this-> user_model-> uppdatering ($ this-> post ('id'), array ('name' => $ this-> inlägg '=> $ this-> post (' email '))); om ($ result === FALSE) $ this-> response (array ('status' => 'misslyckades'));  annat $ this-> response (array ('status' => 'framgång'));  funktion users_get () $ users = $ this-> user_model-> get_all (); om ($ användare) $ this-> response ($ users, 200);  annat $ this-> svar (NULL, 404); ?>

Detta visar ett exempel API med några generiska modellnamn. I den första metoden plockar vi upp en? Id = XX och skickar den till modellen. Om data hittas skickar vi den till funktionen $ this-> response () med en status 200. Om inget hittas returnerar du ingen kropp och en 404 för att säga att ingenting hittades. Du kan föreställa dig hur detta kan utökas för att köra alla typer av API-aktiviteter för din webbapplikation.

Steg 5: Säkra API

Nu är ditt API byggt det behöver säkras så att endast användare som får tillgång kan interagera med API: n. För att ställa in inloggningstypen öppnas användarnamn och lösenord "Application / config / rest.php" inuti din kodbas.

/ * | ----------------------------------------------- --------------------------- | REST Logga in | ----------------------------------------------- --------------------------- | | Är inloggning krävs och i så fall vilken typ av inloggning? | | "= ingen inloggning krävs," basic "= relativt säker inloggning," digest "= säker inloggning | * / $ config ['rest_auth'] = 'basic';

Ingen

Vem som helst kan interagera med någon av dina API-kontrollanter.

Grundläggande

En relativt osäker inloggningsmetod som endast bör användas på interna / säkra nät.

Smälta

En mycket säkrare inloggningsmetod som krypterar användarnamn och lösenord. Om du vill ha ett skyddat API som alla kan komma åt, använd digest.

/ * | ----------------------------------------------- --------------------------- | REST Logga in användarnamn | ---------------------------------------------- ---------------------------- | | Array av användarnamn och lösenord för inloggning | | array ('admin' => '1234') | * / $ config ['rest_valid_logins'] = array ('admin' => '1234');

Att konfigurera användarna är enkelt. Varje inloggning är ett matrisobjekt med en nyckel och ett värde. Nyckeln är användarnamnet och värdet är lösenordet. Lägg till så många som du gillar i den här matrisen och rätta ut dem till alla som kommer att använda API: n.

Del 2 - Samverkan med RESTful tjänster

Oavsett om det är det API du just har byggt eller en offentlig tjänst som Twitter, vill du kunna interagera med det på något sätt. Att se till att RESTful tjänster fungerar med grundläggande HTTP-förfrågningar är det mycket enkelt att göra detta på ett antal olika sätt.

Olika metoder att interagera med REST

Var och en av dessa olika interaktionsmetoder kommer att visas med koden placerad direkt i Controller-metoderna. Det här är rent så att demon är lättare att läsa och skulle normalt placeras inuti en modell eller ett bibliotek för korrekt MVC-separation.

file_get_contents ()

Med hjälp av den mycket enkla PHP-funktionen file_get_contents () kan du utföra en grundläggande GET-förfrågan. Detta är den mest grundläggande av alla metoder men är värt att nämna för de "snabba och smutsiga" stunderna.

$ user = json_decode (file_get_contents ('http://example.com/index.php/api/user/id/1/format/json')); echo $ user-> name;

Det är värt att notera att även om den här metoden inte fungerar med HTTP Digest-autentisering, kan du använda följande syntax för att få data från ditt lösenordsskyddade RESTful API om du använder HTTP Basic-autentisering:

$ user = json_decode (file_get_contents ('http: // admin: [email protected]/index.php/api/user/id/1/format/json')); echo $ user-> name;

Det finns några problem med att använda den här metoden: det enda sättet att ställa in extra HTTP-rubriker är att ställa in dem manuellt med hjälp av PHP-funktionen stream_context_create (), vilket kan vara mycket komplicerat för utvecklare som är nya för de interna funktionerna för HTTP-förfrågningar. En annan nackdel är att du bara tar emot kroppen av HTTP-svaret i dess råformat, vilket innebär att du behöver hantera omvandling från en enda begäran.

ringla

cURL är det mest flexibla sättet att interagera med ett REST API som det var utformat för exakt denna typ av sak. Du kan ställa in HTTP-rubriker, HTTP-parametrar och mycket mer. Här är ett exempel på hur du uppdaterar en användare med vårt exempel_api och cURL för att göra en POST-förfrågan:

 funktion native_curl ($ new_name, $ new_email) $ användarnamn = 'admin'; $ password = '1234'; // Alternativ JSON version // $ url = 'http://twitter.com/statuses/update.json'; // Ställ in och kör curlprocessen $ curl_handle = curl_init (); curl_setopt ($ curl_handle, CURLOPT_URL, 'http: //localhost/restserver/index.php/example_api/user/id/1/format/json'); curl_setopt ($ curl_handle, CURLOPT_RETURNTRANSFER, 1); curl_setopt ($ curl_handle, CURLOPT_POST, 1); curl_setopt ($ curl_handle, CURLOPT_POSTFIELDS, array ('name' => $ new_name, 'email' => $ new_email)); // Valfritt, ta bort den här raden om ditt API är öppet curl_setopt ($ curl_handle, CURLOPT_USERPWD, $ användarnamn. ':'. $ Lösenord); $ buffert = curl_exec ($ curl_handle); curl_close ($ curl_handle); $ result = json_decode ($ buffert); om (isset ($ result-> status) && $ result-> status == 'success') echo 'Användaren har uppdaterats.';  annars echo "Något har gått fel"; 

Samverkan med ditt API fungerar så bra, men det finns två problem med den här metoden:

  1. Den använder en ful förvirrande syntax - föreställ dig att skapa flera applikationer baserade på det.
  2. cURL är inte installerat på alla servrar som standard.

För att lösa denna fula syntax har ett cURL-bibliotek utvecklats för CodeIgniter som förenklar saker oerhört.

Exakt samma förfrågan som gjordes med cURL-biblioteket skulle se ut så här:

 funktion ci_curl ($ new_name, $ new_email) $ användarnamn = 'admin'; $ password = '1234'; $ This-> last> bibliotek (curl '); $ This-> curl-> skapa (http: //localhost/restserver/index.php/example_api/user/id/1/format/json '); // Valfritt, ta bort den här raden om ditt API är öppet $ this-> curl-> http_login ($ användarnamn, $ lösenord); $ this-> curl-> post (array ('name' => $ new_name, 'email' => $ new_email)); $ result = json_decode ($ this-> curl-> execute ()); om (isset ($ result-> status) && $ result-> status == 'success') echo 'Användaren har uppdaterats.';  annars echo "Något har gått fel"; 

Mycket trevligare att titta på rätt? Jo det finns en ännu enklare metod att arbeta med REST i dina CodeIgniter-applikationer så här.

REST klient bibliotek

Ett REST-klientbibliotek har utvecklats som sitter ovanpå detta cURL-bibliotek som hanterar formatkonvertering, HTTP-inloggningar och flera andra aspekter av ditt REST API.

 funktionen rest_client_example ($ id) $ this-> load-> library ('vila', array ('server' => 'http: //localhost/restserver/index.php/example_api/', 'http_user' => ' admin ',' http_pass '=>' 1234 ',' http_auth '=>' basic '// eller' digest ')); $ user = $ this-> rest-> get ('användare', array ('id' => $ id), 'json'); echo $ user-> name; 

Här kan du se att vi gör en GET-förfrågan, skickar id som en parameter och berättar för biblioteket som vi vill ha 'json' som innehållsformat. Detta hanterar inställningen av innehållstyp för dig och konverterar data till ett PHP-objekt för dig. Du kan ändra det här värdet till "xml", "json", "serialize", "php", "csv" eller någon anpassad MIME-typ du gillar, till exempel:

 $ user = $ this-> rest-> get ('användare', array ('id' => $ id), 'application / json');

Som du antagligen har gett samt $ this-> rest-> get (), stöder biblioteket även $ this-> rest-> post (), $ this-> rest-> put (), $ this-> resten -> delete () för att matcha alla dina REST_Controller metoder.

Du måste få var_dump () resultat från REST-klientbiblioteket för att se till att du får rätt dataformat tillbaka. Omvandlingen kommer ibland att vara array och ibland vara ett objekt, beroende på hur det konverteras av PHP. Om den returnerade MIME-typen inte stöds kommer den helt enkelt att returnera formatet som vanlig text.

Pratar med Twitter

Med hjälp av detta REST-bibliotek kan du prata andra RESTful tjänster som Twitter och Facebook. Här är ett enkelt exempel på hur du kan få detaljer för en specfic användare baserat på deras ID, med hjälp av Twitters standardformat XML.

 $ this-> load-> library ('resten', array ('server' => 'http://twitter.com/')); $ user = $ this-> rest-> get ('användare / visa', array ('screen_name' => 'philsturgeon'));
 $ this-> load-> library ('resten', array ('server' => 'http://twitter.com/', 'http_user' => 'användarnamn', 'http_pass' => 'lösenord' http_auth '=>' basic ')); $ user = $ this-> rest-> post ('statuses / update.json', array ('status' => 'Använda REST-klienten för att göra saker'));

Om du tittar på det här märker du att interaktion med Twitter API är lite annorlunda på några sätt.

  1. De stöder URL-baserad formatväxling i form av .json istället för / format / json. Vissa kräver en förlängning, vissa gör det inte; så det är bäst att alltid lägga till dem.
  2. De stöder mestadels bara GET / POST, men börjar lägga till fler DELETE-metoder
  3. De har inte alltid bara en resurs i deras webbadress, till exempel: användare / sök är en REST-metod, men listor är en annan.

Håll koll på dessa skillnader eftersom de kan ta dig ut. Om du fastnar, enkelt echo $ this-> rest-> debug () för en mängd information på din REST-förfrågan.

Sammanfattning

Kombinera vad du nu vet om RESTful tjänster, CodeIgniter REST klient bibliotek och Twitter API dokumentation - eller någon annan RESTful API dokumentation för den delen - du kan skapa några mycket kraftfulla applikationer som integreras med någon anpassad eller offentlig webbtjänst med hjälp av REST. Du kan förlänga ditt API genom att skapa mer REST_Controller och till och med göra ett modulärt API genom att använda Matchbox eller Modular Separation för att skapa en api.php-kontroller för varje modul för att hålla ditt API så snyggt organiserat som din ansökan.

Följ oss på Twitter, eller prenumerera på Nettuts + RSS-flödet för de bästa webbutvecklingsstudierna på webben. Och glöm inte att kolla in de användbara CodeIgniter-skript och -program på Envato Market.