Share
In deze serie hebben we de wp_remote_get WordPress HTTP API-functie om te begrijpen hoe het werkt, hoe we het kunnen gebruiken en welke optionele argumenten het accepteert.
Vanaf hier kunnen we gedetailleerde aanvragen schrijven; dat is echter slechts de helft - er is ook het antwoord.
In het tweede artikel hebben we gekeken naar hoe een basisantwoord eruit zou zien, hoe dit zou kunnen worden geëvalueerd en hoe het op het scherm zou kunnen worden weergegeven, maar we hebben niet echt in detail over het antwoord gesproken.
Als u meer geavanceerde verzoeken wilt schrijven en meer defensieve code wilt schrijven, is het belangrijk om de gegevens te begrijpen die als een reactie worden verzonden. In dit laatste artikel gaan we precies dat doen.
Ten eerste is het belangrijk om te begrijpen wat ik bedoel met het schrijven van defensieve code: bij het schrijven van software moeten we vaak met de cases werken dat een gebruiker iets verkeerd kan doen, invoer verkeerd kan zijn ingesteld of gegevens kunnen worden opgehaald of ontvangen, zoals in het geval van een antwoord - niet correct.
Daartoe coderen we defensief tegen die scenario's zodat onze software niet volledig crasht of bombarderen terwijl de gebruiker het gebruikt. In plaats daarvan mislukt het sierlijk en blijft het uitvoeren.
Door te weten wat de functie precies ontvangt als antwoord op zijn verzoek, weten we welke gegevens moeten worden opgezocht en hoe de kwestie sierlijk kan worden afgehandeld wanneer deze niet terugkomt zoals we verwachten.
Laten we eens kijken naar een voorbeeld van een reactie om de weg te bereiden voor wat we kunnen verwachten. Laten we zeggen dat je een moet maken KRIJGEN verzoek om een URL die een eenvoudig stukje tekst aan u retourneert.
Over het algemeen kunt u verwachten dat u ingewikkeldere aanvragen doet waarbij de respons XML of JSON of iets anders is; al deze informatie zal echter worden ingesteld in de lichaam index van de responsarray. Dus als u begrijpt wat u kunt verwachten, begrijpt u hoe u ermee om moet gaan.
Dat gezegd hebbende, is dit de reactie die je zou kunnen verwachten van een eenvoudig verzoek aan een domein dat niets anders dan gewone tekst retourneert.
Array ([headers] => Array ([datum] => Thu, 30 Sep 2010 15:16:36 GMT [server] => Apache [x-powered-by] => PHP / 5.3.3 [x-server] => 10.90.6.243 [verloopt] => Do, 30 Sep 2010 03:16:36 GMT [cache-control] => Array ([0] => no-store, no-cache, must-revalidate [1] = > post-check = 0, pre-check = 0) [vary] => Accept-Encoding [content-length] => 1641 [connection] => close [content-type] => application / php) [body] = > 'Een simpel stukje tekst'. [Response] => Array ([code] => 200 [bericht] => OK) [cookies] => Array ())
Niets meer dan een array (of eigenlijk een array van arrays). Niets te slecht, toch?
Laten we elk van de responselementen in detail bekijken.
Zoals je kunt zien aan de bovenstaande reactie, zijn de headers eigenlijk samengesteld uit een andere array die uit andere informatie bestaat.
Voordat we naar elk stuk van de bovenstaande informatie kijken, is het belangrijk om te begrijpen wat precies een header is. Kort gezegd geven headers informatie over de verzoek / responscommunicatie die bestaat tussen de client en de server.
Er is een grote verscheidenheid aan headers die teruggestuurd kunnen worden (waarvan vele buiten het bestek van dit artikel vallen), maar die ons allemaal helpen informatie te verkrijgen over het verzoek, maar over de server waarmee we zijn communiceren.
Met dat gezegd, laten we elk header-element in detail bekijken.
Het is duidelijk dat dit een uitzonderlijk eenvoudig element is om te begrijpen: eenvoudig gezegd, dit is de datum en tijd waarop het bericht werd verzonden. Het bevat uiteraard de dag, datum en tijd in Greenwich Mean Time, een wereldwijde standaard van tijd.
Het serverelement verwijst naar het type software waarop de server draait. Vaker wel dan niet, zult u waarschijnlijk Apache zien; er zijn echter nog andere servertoepassingen beschikbaar, zoals IIS en de up and coming Nginx.
X-Powered-By verwijst naar de serversoftware die de transactie van de communicatie aanstuurt. In ons geval zien we PHP, wat eenvoudig betekent dat ons verzoek is verzonden naar een server met Apache en PHP.
Dit is echter niet altijd het geval.
U kunt bijvoorbeeld communiceren met een server waarop nginx en Python worden uitgevoerd of met een ander type serversoftware met Ruby on Rails.
Dit specifieke antwoordelement verwijst naar het IP-adres van de server waarnaar het verzoek is verzonden. Ik heb deze specifieke informatie zelden nodig gehad; Als u echter een onverwacht antwoord krijgt ondanks het feit dat alle andere informatie in orde lijkt, kan het helpen om te weten of het IP-adres van de server overeenkomt met wat u zou verwachten voor het domein waarnaar het verzoek wordt verzonden.
Telkens wanneer een verzoek wordt gedaan en een antwoord wordt verzonden, heeft het antwoord bij wijze van spreken een levensduur.
Meer in het bijzonder zal het antwoord na een bepaalde tijdsperiode als "oud" worden beschouwd. Het is duidelijk dat het tijdstip waarop het antwoord als verouderd wordt beschouwd, is wanneer het antwoord zou zijn verlopen.
Hoe lang een antwoord als niet-oud wordt beschouwd, is gebaseerd op de configuratie van de server, maar de tijdstempel heeft hetzelfde formaat als de datum van het verzoek.
Cache-controle verwijst naar het idee dat een webbrowser (of een ander cachingmechanisme dat op zijn plaats is tussen de client en de server) al dan niet in staat is om het eerste antwoord te gebruiken als het antwoord voor toekomstige verzoeken.
Bijvoorbeeld als een server antwoordt no-cache, dan betekent dit dat de browser, server of andere proxy-software of cachingmechanisme van de aanvragende machine elk antwoord moet behandelen als een nieuw antwoord. Als, aan de andere kant, no-cache is niet opgegeven, dan is de eerste reactie mogelijk het enige antwoord dat u kunt krijgen (in ieder geval totdat de cache is ingesteld om te verlopen).
Dit bestaat uiteraard uit twee indexen:
Accentsconagua
no-cache is vastgesteldpost-check en de controle vooraf Als het interval is verlopen, wordt er een nieuwere versie van de gegevens aangevraagd; anders wordt een in cache opgeslagen versie opgehaald.Dit specifieke aspect van caching valt buiten het bereik van deze serie, omdat er veel meer kan worden geschreven en uitgelegd; de bovenstaande definitie moet echter voldoende zijn om de headers die u ziet te helpen verklaren.
Deze header-waarde is vergelijkbaar met de Cache-Control-header, omdat deze aan de verzoekende servers vertelt hoe vergelijkbare, daaropvolgende aanvragen moeten worden afgehandeld.
In het algemeen zal dit de server instrueren of een cachereactie al dan niet kan worden gebruikt, of dat een nieuwe waarde moet worden opgehaald. Dit is een ander element dat te gecompliceerd kan raken, maar om de uitleg te kunnen distilleren in iets dat meer in de scope ligt van wat we bespreken, kan het header-element ook de server instrueren over de verschillende inhoudstypen die de cliënt kan verwerken.
In het bovenstaande voorbeeld geven we de server opdracht dat onze client gecodeerde informatie kan verwerken.
Inhoud-lengte is een eenvoudig concept met een enkele gotcha: ten eerste, het bepaalt eenvoudig de lengte van het lichaam van het antwoord.
Het ding is, het doet het in 8-bits bytes. Dit betekent dat het antwoord niet wordt weergegeven in kilobytes, megabytes of welke gegevens we ook gebruiken.
Hiertoe moet u wellicht een conversie uitvoeren als u meer rijke informatie wilt verzamelen over de gegevens die worden geretourneerd.
De verbindingswaarde geeft aan welk type verbinding de aanvragende browser prefereert. Hierboven zien we dat de waarde is gedefinieerd als "dichtbij", wat betekent dat zodra het antwoord is verzonden, de verbinding kan worden gesloten.
Er zijn echter nog andere alternatieven. U kunt bijvoorbeeld "keep-alive" krijgen, die uiteraard de verbinding enige tijd in leven wil houden.
Nogmaals, dit is een ander voorbeeld van iets dat een eigen artikel zou vereisen om volledig te bespreken; dit geeft echter wel inzicht in het type verbinding dat de server het liefst heeft, wat u kan helpen bij het samenstellen van toekomstige aanvragen.
Dit is echt alleen relevant voor beide POST en DUWEN verzoeken. In het kort, dit definieert het lichaamstype van de verzoeken.
Dit kan variëren op basis van de gegevens die worden verzonden. Soms is het een gecodeerde URL, soms is het PHP, soms is het iets anders. Hoe dan ook, dit helpt ervoor te zorgen dat we kunnen controleren of de gegevens die terugkomen in de inhoud in overeenstemming zijn met wat we verwachten gezien ons verzoek.
Het body-element bevat eigenlijk de informatie die wordt geretourneerd door de server.
In ons voorbeeld van twee artikelen geleden ontvingen we een JSON-reeks van Twitter. In het bovenstaande voorbeeld ontvangen we een eenvoudige tekenreeks. Uiteindelijk kan de reactie terugkomen als een vorm van binaire gegevens die een niveau van de-serialisatie nodig zou hebben.
Hoe het ook zij, het is aan ons als uitvoerders van het verzoek om te weten hoe het antwoord correct moet worden gedecodeerd voordat het aan onze gebruikers wordt getoond..
Het antwoord verwijst eigenlijk naar de HTTP-antwoordcode die van de server naar de aanvragende client wordt gestuurd. Als u niet bekend bent met HTTP-statuscodes, raad ik u aan HTTPStat.us te raadplegen voor een heel goede referentie.
Kort gezegd, een antwoord bestaat uit een numerieke code en een tekstbericht om het resultaat van het verzoek aan te geven.
In het bovenstaande voorbeeld kunt u zien dat we de statuscode '200' en het bericht 'OK' hebben ontvangen. De code en het berichtenpaar moeten altijd synchroon zijn met elkaar.
Dit betekent dat als je een '403' ontvangt, je ook een 'Verboden' moet ontvangen, of als je een '404' ontvangt, dan zou je een 'niet gevonden' bericht moeten ontvangen.
Persoonlijk heb ik vastgesteld dat deze specifieke waarden belangrijk zijn voor het stellen van de diagnose wanneer er problemen zijn ontstaan met verzoeken die ik heb gedaan.
Ten slotte verwijst de cookie-array naar alle informatie die via de draad is verzonden op basis van de cookies die bestaan tussen de huidige client en de server die de communicatie maken..
Afhankelijk van de aard van uw verzoek is dit al dan niet leeg. Dit varieert te veel per geval om een definitieve gids te bieden. Kortom, als er geen cookies zijn vastgesteld tussen de twee verbindingen, dan is deze waarschijnlijk altijd leeg; anders worden de gegevens die de cookie-array bevatten specifiek gebaseerd op de cookies die tussen de twee services bestaan.
Over het geheel genomen is er een behoorlijke hoeveelheid gegevens en het zullen variëren van aanvraag tot aanvraag op basis van wat u wilt ontvangen en op basis van de reactie van de server; het punt is echter dat je het nu weet wat te verwachten en op de juiste manier om te gaan met alle zaken.
Als het slechter gaat met je werk, kun je altijd een debugger gebruiken of gewoon wat foutopsporingsopdrachten plaatsen, zoals print_r of var_dump om te zien wat de server teruggeeft, zodat u de fouten netjes kunt afhandelen.
Later zullen we de WordPress HTTP API opnieuw bezoeken om andere methoden te onderzoeken, zoals wp_remote_post en wp_remote_request zodat we een volledig beeld krijgen van de HTTP API.
Tot die tijd zal deze serie u hopelijk een even diepgaande verslaggeving hebben opgeleverd wp_remote_get om niet alleen uw werk te verbeteren, maar ook om uw nieuwsgierigheid te kweken over wat er nog meer mogelijk is als het gaat om aanvragen op afstand.
