Maak een REST API met PHP

Gepost op 28 januari 2012 greenhawk

Een van de laatste (soort van) rages het vegen van het net is API's, meer bepaald die die gebruikmaken van REST. Het is echt geen verrassing zijn, omdat consumeren REST API's is zo ongelooflijk makkelijk ... in elke taal. Het is ook ongelooflijk eenvoudig te maken ze als je in wezen te gebruiken niets meer dan een HTTP-spec, dat bestaat al eeuwen. Een van de weinige dingen die ik Rails krediet geven voor is zijn doordachte REST-ondersteuning, zowel voor het leveren en consumptie van deze API's (zoals de was te verklaren door al de Rails fanboys waar ik mee werk).

Serieus, als je nog nooit hebt REST gebruikt, maar je ooit hebt gehad om te werken met (of erger nog, maak) een SOAP API, of gewoon opende een WSDL en had je hoofd ontploft, jongen heb ik goed nieuws voor u!

Dus, wat op aarde is REST? Waarom dat belangrijk voor je?

Voordat we in het schrijven van een stukje code, wil ik ervoor zorgen dat iedereen er een goed inzicht gekregen van wat REST is en hoe zijn grote voor de API's. Ten eerste, technisch gezien, REST niet specifiek is om gewoon API's, het is meer een algemeen begrip. Maar uiteraard, in het belang van dit artikel zullen we er over te praten in het kader van een API. Dus, laten we eens kijken naar de basisbehoeften van een API en hoe REST behandelt hen.

Verzoeken
Alle API's nodig hebt om te accepteren. Meestal met een rustgevende API, heb je een goed gedefinieerde URL-schema. Laten we zeggen dat u een API te bieden voor gebruikers op uw site (ik weet, heb ik altijd de "gebruikers"-concept gebruiken voor mijn voorbeelden). Nou, je URL-structuur zou waarschijnlijk zoiets als: "api / gebruikers" en "api / users / [id]", afhankelijk van de aard van de gevraagde bewerking tegen uw API. Je moet ook nadenken over hoe u gegevens wilt accepteren. Deze dagen veel mensen maken gebruik van JSON of XML, en ik persoonlijk de voorkeur JSON omdat het werkt goed met JavaScript, PHP en heeft een gemakkelijke functionaliteit voor het coderen en decoderen. Als je wilde uw API om echt robuust, kan u akkoord met zowel door snuiven van de content-type van het verzoek (dat wil zeggen application / json of application / xml), maar het is perfect aanvaardbaar om dingen te beperken tot een type inhoud. Heck, kun je zelfs gebruik maken van eenvoudige sleutel / waarde paren als je wilde.

Het andere stuk van een verzoek is wat het eigenlijk is bedoeld om doen, zoals laden, opslaan, etc. Normaal gesproken zou je moeten komen met een soort van architectuur die welke actie de aanvrager (consumenten) wensen bepaalt, maar REST vereenvoudigt dat. Door het gebruik van HTTP-verzoek methoden, of werkwoorden, hoeven we niet om iets te definiëren. We kunnen gewoon gebruik maken van de GET, POST, PUT en DELETE methoden, en dat heeft betrekking op elk verzoek zouden we nodig hebben. U kunt gelijk de werkwoorden om je standaard CRUD-stijl stuff: GET = belasting / op te halen, POST = maken, PUT = update, delete = goed, te verwijderen. Het is belangrijk op te merken dat deze werkwoorden niet rechtstreeks te vertalen naar CRUD, maar het is een goede manier om na te denken over hen. Dus, terug te gaan naar de bovenstaande URL voorbeelden, laten we eens kijken naar wat een aantal mogelijke vragen zou kunnen betekenen:

GET verzoek / api / gebruikers - Geef een overzicht van alle gebruikers
GET verzoek / api/users/1 - Lijst informatie voor de gebruiker met ID van 1
POST-aanvraag naar / api / gebruikers - Maak een nieuwe gebruiker
PUT verzoek / api/users/1 - Update gebruiker met ID van 1
DELETE verzoek / api/users/1 - Delete gebruiker met ID van 1

Zoals je hopelijk te zien, heeft REST al voor gezorgd veel van de belangrijkste kopzorgen van het creëren van uw eigen API via een aantal eenvoudige, goed begrepen standaarden en protocollen, maar er is een ander stuk om een goede API ...

Reacties
Dus, REST behandelt verzoeken heel gemakkelijk, maar het maakt ook het genereren van reacties gemakkelijk. Net als bij aanvragen, zijn er twee belangrijke componenten van een goede respons: de respons lichaam, en een status code. De reactie lichaam is vrij eenvoudig te behandelen. Net als verzoeken, de meeste reacties in de rest zijn meestal ofwel JSON of XML (misschien alleen platte tekst in het geval van de ambten, maar we zullen dat later te dekken). En, net als verzoeken, kan de consument geeft u de reactie van het type ze willen een ander deel van het HTTP-verzoek spec, "Accepteren". Als een consument wenst te ontvangen van een XML-reactie, zouden ze gewoon stuur een header te accepteren als een deel van hun verzoek zeggen zo veel ("Accept: application / xml"). Toegegeven, wordt deze methode niet zo breed aangenomen (tho het zou moeten zijn), dus je moet ook het concept van een uitbreiding in de URL te gebruiken. Bijvoorbeeld, / api / users.xml betekent dat de consument wil XML als een reactie, net / api / users.json betekent JSON (idem voor dingen als / api/users/1.json/xml). Hoe dan ook je kiest (Ik zeg beide doen), moet u een standaard reactie van het type kiezen als een groot deel van de tijd die mensen gewoon 'even vertellen wat ze willen. Nogmaals, ik zou zeggen ga met JSON. Dus geen Accept header of uitbreiding (dwz / api / gebruikers) mogen niet falen, het moet gewoon fail-over naar de standaard reactie-type.

Maar hoe zit het met fouten en andere belangrijke status van berichten in verband met verzoeken? Gemakkelijk, gebruik van HTTP status code! Dit is ver en boven een van mijn favoriete dingen over het maken van RESTful API's. Door het gebruik van HTTP-statuscodes, je niet hoeft te komen met een fout / succes regeling voor uw API, het is al voor u gedaan. Bijvoorbeeld, als een consument Posten / api / gebruikers en u wilt rapporteren een succesvolle creatie, stuur gewoon een 201 status code (201 = Gemaakt). Als het mislukt, stuur dan een 500 als het niet op uw einde (500 = Internal Server Error), of misschien een 400 als ze verpest (400 = Slecht aanvraag). Misschien worden ze op probeert te plaatsen tegen een API eindpunt dat niet accepteert berichten ... stuur dan een 501 (Niet geïmplementeerd). Misschien is uw MySQL server down is, zodat je API is tijdelijk borked ... stuur dan een 503 (Service niet beschikbaar). Hopelijk krijg je het idee. Als u wilt lezen een beetje over de status codes, bekijk ze op Wikipedia: Lijst van HTTP Status Codes .

Ik hoop dat je alle voordelen die u krijgt te zien door gebruik te maken van de concepten van rust voor je API's. Het is echt super-cool, en het is een schande het is niet meer op grote schaal over gesproken in de PHP-gemeenschap (althans voor zover ik kan zien). Ik denk dat dit waarschijnlijk te wijten aan het gebrek aan goede documentatie over hoe om te gaan met verzoeken die niet GET of POST, namelijk PUT en DELETE. Toegegeven, het is een beetje goofy het omgaan met deze, maar het is zeker niet moeilijk. Ik ben ook zeker een aantal van de populaire kaders die er zijn waarschijnlijk een soort van REST implementatie hebben, maar ik ben niet een grote kader ventilator (voor een heleboel redenen dat ik niet zal krijgen in), en het is ook goed om te weten deze dingen, ook als iemand al is de oplossing voor u gemaakt.

Als je nog steeds niet van overtuigd dat dit een bruikbare API paradigma, een kijkje nemen naar wat rest is voor Ruby on Rails gedaan. Een van de belangrijkste aanspraak op roem is hoe gemakkelijk het is om API's (via een soort van RoR voodoo, ik ben er zeker van), en terecht. Toegegeven Ik weet heel weinig over ROR, maar de fanboys rond het kantoor gepredikt hebben dit punt voor mij vele malen. Maar, ik dwaal af ... laten we schrijven wat code!

Aan de slag met REST en PHP

Een laatste ontkenning: de code die we staan op het punt om te gaan dan is op geen enkele wijze bedoeld om te worden gebruikt als een voorbeeld van een robuuste oplossing. Mijn voornaamste doel hier is om te laten zien hoe om te gaan met de individuele componenten van REST in PHP, en laat het maken van de uiteindelijke oplossing aan jou.

Dus, laten we graven in! Ik denk dat de beste manier om iets praktisch te doen is het creëren van een klasse die zal alle nutsfuncties moeten we een REST API te creëren. We zullen ook een kleine klasse voor het opslaan van onze gegevens. U kunt ook neem dan dit, uitbreiden, en toepassen op uw eigen behoeften. Dus, laten we stomp some stuff out:

 klasse RestUtils
 {
	 public static functie processRequest ()
	 {

	 }

	 public static functie sendResponse ($ status = 200, $ body ='', $ content_type = 'text / html ")
	 {

	 }

	 public static functie getStatusCodeMessage ($ status)
	 {
		 / / Deze kunnen worden opgeslagen in een. Ini-bestand en geladen
		 / / Via parse_ini_file () ...  zal dit echter volstaan
		 / / Een voorbeeld
		 $ Codes = Array (
		     100 => 'Doorgaan',
		     101 => 'Switching Protocollen',
		     200 => 'OK',
		     201 => 'Gemaakt',
		     202 => 'Accepted',
		     203 => 'Niet toegankelijke informatie',
		     204 => 'Geen inhoud',
		     205 => 'Reset inhoud',
		     206 => 'Gedeeltelijke inhoud',
		     300 => 'Multiple Choices',
		     301 => 'Permanent verplaatst',
		     302 => 'gevonden',
		     303 => 'Zie Andere',
		     304 => 'Niet aangepast',
		     305 => 'Proxy gebruiken',
		     306 => '(ongebruikt)',
		     307 => 'Tijdelijke Redirect',
		     400 => 'Bad Request',
		     401 => 'zonder toestemming',
		     402 => 'Betaling vereist',
		     403 => 'Forbidden',
		     404 => 'niet gevonden',
		     405 => 'Methode niet toegestaan',
		     406 => 'Niet acceptabel',
		     407 => 'Proxy Authentication Required',
		     408 => 'Request Time-out',
		     409 => 'Conflict',
		     410 => 'Gone',
		     411 => 'Lengte vereist',
		     412 => 'Voorwaarde mislukt',
		     413 => 'Request Entity Too Large',
		     414 => 'Request-URI Too Long',
		     415 => 'Niet-ondersteund mediatype',
		     416 => 'Gevraagd bereik niet beschikbaar',
		     417 => 'Verwachting is mislukt',
		     500 => 'Internal Server Error',
		     501 => 'Niet geïmplementeerd',
		     502 => 'Bad Gateway',
		     503 => 'Service niet beschikbaar',
		     504 => 'Gateway Time-out',
		     505 => 'HTTP versie niet ondersteund'
		 );

		 return (isset ($ codes [$ status]))?  $ Codes [$ status]:'';
	 }
 }

 klasse RestRequest
 {
	 private $ request_vars;
	 prive-$ data;
	 private $ HTTP_ACCEPT;
	 private $ methode;

	 publieke functie __ construct ()
	 {
		 $ This-> request_vars = array ();
		 $ This-> data ='';
		 $ This-> HTTP_ACCEPT = (strpos ($ _SERVER ['HTTP_ACCEPT'], 'json'))?  'Json': 'xml';
		 $ This-> method = 'get';
	 }

	 publieke functie setData ($ data)
	 {
		 $ This-> data = $ data;
	 }

	 publieke functie setMethod ($ methode)
	 {
		 $ This-> method = $ methode;
	 }

	 publieke functie setRequestVars ($ request_vars)
	 {
		 $ This-> request_vars = $ request_vars;
	 }

	 publieke functie getData ()
	 {
		 return $ this-> data;
	 }

	 publieke functie getMethod ()
	 {
		 return $ this-> methode;
	 }

	 publieke functie getHttpAccept ()
	 {
		 return $ this-> HTTP_ACCEPT;
	 }

	 publieke functie getRequestVars ()
	 {
		 return $ this-> request_vars;
	 }
 }

OK, dus wat we hebben is een eenvoudige klasse voor het opslaan van wat informatie over ons verzoek (RestRequest), en een klasse met een aantal statische functies die we kunnen gebruiken om te gaan met verzoeken en antwoorden. Zoals u kunt zien, hebben we eigenlijk maar twee functies te schrijven ... dat is het mooie van dit hele gebeuren! Juist, laten we verder gaan ...

Het verwerken van de aanvragen

Het verwerken van de aanvraag is vrij straight-forward, maar dit is waar we lopen in een paar vangsten (namelijk ten PUT en DELETE ... meestal PUT). We gaan op die in een moment, maar laten we eens kijken naar de RestRequest klasse een beetje. Als je kijkt naar de aannemer, zul je zien dat we al zijn de HTTP_ACCEPT header interpreteren en in gebreke te JSON als er geen wordt verstrekt. Met dat uit de weg, moeten we alleen bezighouden met de binnenkomende gegevens.

Er zijn een paar manieren waarop we zouden kunnen gaan over dit te doen, maar laten we aannemen dat we altijd zal een sleutel / waarde paar in ons verzoek te krijgen: 'data' => feitelijke gegevens. Laten we ook aannemen dat de werkelijke gegevens zal JSON. Zoals in mijn vorige verklaring van rust, kun je kijken naar de content-type van het verzoek en kunnen omgaan met een JSON of XML, maar laten we het simpel te houden voor nu. Dus, ons proces om deze functie eindigen op zoek iets als dit:

 public static functie processRequest () {/ / haal onze werkwoord $ REQUEST_METHOD = strtolower ($ _SERVER ['REQUEST_METHOD']); $ return_obj = new RestRequest (); / / we hier $ data = array () op te slaan onze gegevens; switch ($ REQUEST_METHOD) {/ / krijgt zijn gemakkelijk ...  geval 'krijgen': $ data = $ _GET, pauze, / / zo zijn berichten case 'post': $ data = $ _POST, pauze, / / hier is het lastig iets ...  case 'put': / / eigenlijk, lezen we een string van speciale ingang locatie van PHP, / / en dan het uit te ontleden in een array via parse_str ...  per de PHP docs: / / Parseert str alsof het de query string doorgegeven via een URL en sets / / variabelen in de huidige scope.  parse_str (file_get_contents ("php :/ / input '), $ put_vars); $ data = $ put_vars; break;} / / store de methode $ return_obj-> setMethod ($ REQUEST_METHOD); / / zet de ruwe data, dus we toegang kan krijgen als dat nodig is (er kunnen / / andere stukken op uw verzoek) $ return_obj-> setRequestVars ($ data); if (isset ($ data ['data'])) {/ / vertalen van de JSON om een object voor gebruiken zoals je $ return_obj-> setData (json_decode ($ data ['data'])) wilt;} return $ return_obj;}

Zoals ik al zei, mooie straight-forward. Echter, om een paar dingen mee ... Eerst moet je meestal geen gegevens voor DELETE aanvragen te accepteren, zodat we niet een zaak voor hen niet in de schakelaar. Ten tweede, zult u merken dat we beiden het verzoek variabelen, en de geparsed JSON data op te slaan. Dit is handig als u misschien andere dingen hebben als onderdeel van uw aanvraag (laten we zeggen een API-sleutel of zoiets) dat is niet echt de gegevens zelf (zoals een nieuwe gebruikersnaam, e-mail, enz.).

Dus, hoe zouden we deze optie gebruiken? Laten we terug gaan naar de gebruiker voorbeeld. Ervan uitgaande dat u uw aanvraag doorgestuurd naar de juiste controller voor gebruikers, kunnen we een aantal code als volgt uit:

 $ Data = RestUtils :: processRequest ();

 switch ($ data-> getMethod)
 {
	 geval 'krijgen':
		 / / Ophalen een lijst met gebruikers
		 te breken;
	 case 'post':
		 $ User = new User ();
		 $ User-> setFirstName ($ data-> getData () -> voornaam); / / alleen voor bijvoorbeeld, dient dit te gebeuren schoner
		 / / Enzovoort ...
		 $ User-> save ();
		 te breken;
	 / / Etc, etc, etc. ..
 }

Gelieve dit niet te doen in een echte app, dit is gewoon een quick-and-dirty voorbeeld. Je zou dit willen verpakken in een mooie controlestructuur met alles wat geabstraheerd goed, maar dit moet u helpen om een idee van hoe dit spul te gebruiken. Maar ik dwaal af, laten we overgaan tot het verzenden van een reactie.

Het versturen van de Response

Nu kunnen we het verzoek interpreteren, laten we doorgaan met het versturen van de respons. We weten al dat alles wat we echt nodig hebben te doen, is de juiste status code, en misschien wat lichaam (als dit een GET-verzoek, bijvoorbeeld), maar er is een belangrijke vangst op antwoorden die geen lichaam hebben. Zeg iemand een verzoek gedaan tegen onze steekproef gebruiker API voor een gebruiker die niet bestaat (dat wil zeggen api/user/123). De passende status code te sturen is een 404 in dit geval, maar gewoon het versturen van de status van code in de headers is niet genoeg. Als u gezien dat de pagina in uw webbrowser, zou je een leeg scherm. Dit komt omdat Apache (of wat dan ook uw webserver draait op) is niet het verzenden van de status-code, dus er is geen status pagina. We moeten hiermee rekening houden bij het bouwen we onze functie. Houden van alles wat in het achterhoofd, hier is wat de code eruit zou moeten zien:

	 public static functie sendResponse ($ status = 200, $ body ='', $ content_type = 'text / html ") {$ status_header =' HTTP/1.1 '.  $ Status.  '.  RestUtils :: getStatusCodeMessage ($ status); / / stel de status van header ($ status_header); / / stel de content type header ('Content-type: ". $ Content_type); / / pagina' s met het lichaam van zijn eenvoudig if ($ body ! ='') {/ / stuur het lichaam echo $ lichaam; exit;} / / we nodig hebben om het lichaam te maken als er geen is anders doorgegeven {/ / maak een lichaam berichten $ message =''; / / dit is puur optioneel , maar maakt de pagina's een beetje leuker om / / te lezen voor uw gebruikers.  Omdat u waarschijnlijk niet te sturen veel met een verschillende status codes, / / dit ook moet niet te zwaar aan switch ($ status) {case 401 te behouden: $ message = '. U moet gemachtigd om deze pagina te bekijken'; break; case 404: $ message = 'De gevraagde URL'.  $ _SERVER ['REQUEST_URI'].  'Is niet gevonden.'; Break; case 500: $ message = 'De server is een fout opgetreden verwerken van uw verzoek.'; Break; case 501: $ message = '. De gevraagde methode is niet geïmplementeerd'; break;} / / servers hebben niet altijd een handtekening ingeschakeld (dit is een apache richtlijn "ServerSignature On") $ signature = ($ _SERVER ['SERVER_SIGNATURE'] =='')?  $ _SERVER ['SERVER_SOFTWARE'].  'Server bij'.  $ _SERVER ['SERVER_NAME'].  'Port'.  $ _SERVER ['Server_port']: $ _SERVER ['SERVER_SIGNATURE'], / / dit moet worden templatized in een real-world oplossing $ body = '<DOCTYPE HTML PUBLIC "- / / W3C / / DTD HTML 4.01 / / EN! "" http://www.w3.org/TR/html4/strict.dtd "> <head> <meta http-equiv =" Content-Type "content =" text / html; charset = iso-8859 -1 "> <title> '.  $ Status.  '.  RestUtils :: getStatusCodeMessage ($ status).  '</ Title> </ head> <body> <h1>'.  RestUtils :: getStatusCodeMessage ($ status).  '</ H1> <p>'.  $ Bericht.  '</ P> <hr /> <adres>'.  $ Handtekening.  '</ Adres> </ body> </ html>'; echo $ lichaam; exit;}}

Dat is het! We hebben technisch gezien alles wat we nu nodig hebben om aanvragen te verwerken en reacties sturen. Laten we een beetje meer te praten over waarom moeten we een standaard body reactie of een aangepaste een te hebben. Voor GET-verzoeken, dit is vrij duidelijk, we moeten XML / JSON-inhoud in plaats van een status pagina (mits het verzoek geldig was) te sturen. Er is echter ook berichten behandelen. Binnenkant van je apps, wanneer u een nieuwe entiteit te creëren, heb je waarschijnlijk halen van de nieuwe entiteit ID via iets als mysql_insert_id (). Nou, als een gebruiker berichten direct op de API, zullen ze waarschijnlijk willen dat nieuwe ID ook. Wat ik meestal doe is in dit geval stuur van de nieuwe ID als het lichaam (met een 201 status code), maar je zou ook kunnen wikkelen, dat in XML of JSON als u wilt.

Dus, laten we onze steekproef de uitvoering een beetje uit te breiden:

 switch ($ data-> getMethod)
 {
	 / / Dit is een verzoek voor alle gebruikers, niet een in het bijzonder
	 geval 'krijgen':
		 $ User_list = getUserList (); / / aannemen dat dit geeft een array terug

		 if ($ data-> getHttpAccept == 'json')
		 {
			 RestUtils :: sendResponse (200, json_encode ($ user_list), 'application / json');
		 }
		 else if ($ data-> getHttpAccept == 'xml')
		 {
			 / / Gebruikers van de XML_SERIALIZER PEAR pakket
			 $ Options = array
			 (
				 'Streepje' => '',
				 'AddDecl' => false,
				 'RootName' => $ fc-> getAction (),
				 XML_SERIALIZER_OPTION_RETURN_RESULT => true
			 );
			 $ Serializer = new XML_Serializer ($ options);

			 RestUtils :: sendResponse (200, $ serializer-> serialize ($ user_list), 'application / xml');
		 }

		 te breken;
	 / / Nieuwe gebruiker aan te maken
	 case 'post':
		 $ User = new User ();
		 $ User-> setFirstName ($ data-> getData () -> voornaam); / / alleen voor bijvoorbeeld, dient dit te gebeuren schoner
		 / / Enzovoort ...
		 $ User-> save ();

		 / / Stuur de nieuwe ID als het lichaam
		 RestUtils :: sendResponse (201, $ user-> getId ());
		 te breken;
 }

Nogmaals, dit is slechts een voorbeeld, maar het heeft laten zien (denk ik, tenminste) hoe weinig moeite die het kost te implementeren RESTful spul.

Wrapping Up

Zo, dat is het zo'n beetje. Ik ben er vrij zeker van dat ik het punt geslagen dat dit moet vrij eenvoudig in de grond, dus ik wil graag afsluiten met hoe je dit spul verder te nemen en misschien wel correct uit te voeren is.

In een real-world MVC applicatie, wat je waarschijnlijk wilt doen is het opzetten van een controller voor uw API die wordt geladen individuele API-controllers. Bijvoorbeeld met behulp van de bovenstaande dingen, dan zouden we eventueel een UserRestController die vier methoden had: get (), zet (), post () en verwijderen (). De API-controller zou kijken naar de aanvraag en bepalen welke methode zich te beroepen op die controller. Deze methode zou dan de utils te gebruiken om de aanvraag te verwerken, doen wat het moet doen data-wijs, gebruik dan de utils om een reactie te sturen.

U kunt ook een stapje verder dan dat, en abstract uit uw API-controller en data modellen een beetje meer. In plaats van expliciet maken van een controller voor elke data model in uw app, kunt u wel wat logica in uw API-controller toe te voegen om eerst te kijken voor een expliciet gedefinieerd controller, en als er geen gevonden wordt, probeer te zoeken naar een bestaand model. Zo zou de url "api/user/1", eerst leiden tot een lookup voor een "gebruiker" rust controller. Als er geen gevonden wordt, zou het dan zoeken naar een model genaamd "user" in uw app. Als er een gevonden, kun je schrijven een beetje van geautomatiseerde voodoo om automatisch te verwerken alle aanvragen tegen deze modellen.

Gaan nog verder, kun je vervolgens een algemene "lijst-all" methode die werkt op dezelfde manier zoals de vorige paragraaf's. Zeg je url was "api / gebruikers". De API-controller zou eerst zoeken naar de "gebruikers" rust-controller, en als er geen gevonden, erkennen dat gebruikers is pluaralized, depluralize, en dan op zoek naar een "user"-model. Als er een wordt gevonden, moet u een lijst met de lijst van gebruikers en stuur dat uit te schakelen.

Tot slot kon je digest authenticatie toe te voegen aan uw API vrij gemakkelijk ook. Stel dat je alleen goed geverifieerde gebruikers aan uw API-toegang wilde, nou ja, kunt u wel wat code als volgt uit te gooien in uw proces verzoek functionaliteit (geleend van een bestaande app van mij, dus er is een aantal constanten en variabelen verwezen die niet gedefinieerd zijn in dit fragment )

			 / / Uit te vinden of we nodig hebben om de gebruiker te vechten
			 if (empty ($ _SERVER ['PHP_AUTH_DIGEST']))
			 {
				 header ("HTTP/1.1 401 Niet toegestaan ');
				 header ('WWW-Authenticate: Digest realm = "'.. AUTH_REALM '" ".. uniqid ()'", qop = "auth", nonce = ', ondoorzichtige = "'.. md5 (AUTH_REALM)" "') ;

				 / / Toon de fout als ze op te annuleren
				 sterven (RestControllerLib :: error (401, true));
			 }

			 / / Nu, analayze de PHP_AUTH_DIGEST var
			 if (($ data = http_digest_parse ($ _SERVER ['PHP_AUTH_DIGEST'])) |! |! $ auth_username = $ data ['gebruikersnaam'])
			 {
				 / / Geven de fout te wijten aan slechte auth
				 sterven (RestUtils :: sendResponse (401));
			 }

			 / / Tot nu toe, alles is goed, laten we nu het antwoord te bekijken een beetje meer ...
			 $ A1 = md5 ($ data ['gebruikersnaam'] ':' AUTH_REALM ':'.... $ Auth_pass);
			 $ A2 = md5 ($ _SERVER ['REQUEST_METHOD'] ':'.. $ Data ['uri']);
			 $ Valid_response = md5 ($ A1. ':' $ Data ['nonce']. '.:' $ Data ['nc']. '.:' $ Data ['cnonce'].. ':' $ Data. ['qop'] ':' $ A2);..

			 / / Laatste controle ..
			 if ($ data ['response']! = $ valid_response)
			 {
				 sterven (RestUtils :: sendResponse (401));
			 }

Pretty cool stuff, hè? Met een beetje van de code en een aantal slimme logica, kunt u een volledig functionele REST API toe te voegen aan uw applicaties zeer snel. Ik zeg alleen niet dat het concept zowel cheerlead, ik voerde dit spul in een van mijn persoonlijke kaders in ongeveer een halve dag, en bracht toen nog een halve dag het toevoegen van alle soorten van koele magie aan. Als u (de lezer) zijn geïnteresseerd in het zien van mijn uiteindelijke implementatie, stuur me een briefje in de comments en ik zou graag met u delen! Ook als je nog geen leuke ideeën die je wilt delen, moet u die in de comments laten vallen en ... als ik het genoeg, zou ik u zelfs laten gastschrijver uw eigen artikel over het onderwerp!

Tot de volgende keer ...

UPDATE: De veel gevraagde follow-up van dit artikel is geplaatst op: Het maken van RESTful Verzoeken in PHP

Deel dit bericht: