Share
I denne serien har vi tatt en titt på wp_remote_get WordPress HTTP API-funksjonen for å forstå hvordan det fungerer, hvordan vi kan bruke det og de valgfrie argumentene som den aksepterer.
Herfra kan vi skrive detaljerte forespørsler; Det er imidlertid bare halvparten av det - det er også svaret.
I den andre artikkelen tok vi en titt på hva et grunnleggende svar ville se ut, hvordan man skal evaluere det, og hvordan man skal vise det på skjermen, men vi snakket ikke om svaret i detalj.
Hvis du ønsker å skrive mer avanserte forespørsler og skrive mer defensiv kode, er det viktig å forstå dataene som sendes som svar. I denne siste artikkelen skal vi gjøre akkurat det.
Først er det viktig å forstå hva jeg mener ved å skrive defensiv kode: Når du skriver programvare, må vi ofte jobbe med tilfeller som en bruker kan gjøre noe galt, innspillingen kan settes feil, eller data kan hentes eller mottas - for eksempel i tilfelle et svar - feil.
For det formål kodes vi defensivt mot disse scenariene, slik at programvaren vår ikke helt krasjer eller bomber mens brukeren bruker den. I stedet mislykkes det grasiøst og fortsetter å løpe.
Ved å vite hva nøyaktig funksjonen mottar som svar på forespørselen, vet vi hvilke data som skal letes etter, og hvordan håndteres saksomt når det ikke kommer tilbake som vi forventer.
For å sette scenen for hva du kan forvente, la oss ta en titt på et eksempelrespons. La oss si at du skal lage en FÅ Be om en URL som vil returnere en enkel tekstbit til deg.
Vanligvis kan du forvente å gjøre mer kompliserte forespørsler der svaret kan være XML eller JSON eller noe annet; Imidlertid vil all denne informasjonen bli satt inn i kropp indeks av respons array. Så hvis du forstår hva du kan forvente, forstår du hvordan du skal håndtere det.
Med det sagt, dette er svaret du kan forvente å motta fra en enkel forespørsel til et domene som returnerer ingenting annet enn vanlig tekst.
Array ([headers] => Array ([date] => Thu, 30 Sep 2010 15:16:36 GMT [server] => Apache [x-powered-by] => PHP / 5.3.3 [x-server] => 10.90.6.243 [utløper] => torsdag 30 sep 2010 03:16:36 GMT [cache-control] => Array ([0] => ingen butikk, ikke-cache, må-revalidere [1] = > post-check = 0, forhånds-sjekke = 0) [vary] => Accept-Encoding [innholdslengde] => 1641 [tilkobling] => lukk [innholdstype] => søknad / php) > 'En enkel bit av tekst.' [Svar] => Array ([kode] => 200 [melding] => OK) [cookies] => Array ())
Ingenting mer enn en matrise (eller, virkelig, en rekke arrays). Ingenting også dårlig, rett?
La oss se nærmere på hver av responselementene.
Som du kan fortelle fra svaret ovenfor, er topptekstene faktisk sammensatt av en annen matrise som består av annen informasjon.
Før du ser på hvert stykke av informasjonen ovenfor, er det viktig å forstå hva en topptekst er. Kort sagt gir overskrifter informasjon om forespørsel / responskommunikasjon som eksisterer mellom klienten og serveren.
Det finnes et bredt spekter av overskrifter som kan sendes tilbake (hvorav mange er utenfor rammen av denne artikkelen), men alle hjelper oss med å få informasjon ikke bare om forespørselen, men om serveren som vi er kommuniserer.
Med det sagt, la oss se på hvert headerelement i detalj.
Det er klart at dette er et svært enkelt element å forstå: Enkelt sagt, dette er dato og klokkeslett som meldingen ble sendt. Det inkluderer åpenbart dag, dato og klokkeslett alt i Greenwich Mean Time som er en global standard av tid.
Serverelementet refererer til typen programvare som serveren kjører på. Oftere enn ikke, du vil sannsynligvis se Apache; Det finnes imidlertid andre serverapplikasjoner tilgjengelig i dag, for eksempel IIS og up and coming nginx.
X-Powered-By refererer til serverprogramvaren som driver kommunikasjonen av kommunikasjonen. I vårt tilfelle ser vi PHP som bare betyr at vår forespørsel ble sendt til en server som kjører Apache og PHP.
Dette kan ikke alltid være tilfelle, skjønt.
For eksempel kan du ende opp med å kommunisere med en server som kjører nginx og Python, eller en annen type serverprogramvare som kjører Ruby on Rails.
Dette bestemte svarelementet refererer til IP-adressen til serveren som forespørselen sendes til. Jeg har sjelden noensinne trengte å kjenne denne spesifikke informasjonen; men hvis du ender opp med å få en uventet respons til tross for at all annen informasjon ser ut i orden, kan det bidra til å vite om IP-serveren samsvarer med det du vil forvente for domenet som forespørselen sendes til.
Når en forespørsel er gjort og et svar sendes, har svaret en levetid, så å si.
Nærmere bestemt vil svaret bli betraktet som "foreldet" etter en viss tidsperiode. Åpenbart er tiden da svaret blir betraktet uaktivt når responsen sies å være utløpt.
Hvor lenge et svar betraktes som ikke-foreldet, er basert på serverens konfigurasjon, men tidsstempelet har samme format som datoen for forespørselen.
Cache-kontroll refererer til tanken om at en nettleser (eller annen cache-mekanisme som er på plass mellom klienten og serveren) kanskje eller ikke kan bruke det første svaret som svaret for fremtidige forespørsler.
For eksempel, hvis en server svarer med no-cache, da betyr det at den anmodende maskinens nettleser, server eller annen proxy-programvare eller caching-mekanisme må behandle hvert svar som et nytt svar. Hvis, derimot, no-cache er ikke spesifisert, så kan det første svaret være det eneste svaret du kan få (i hvert fall til cachen er satt til å utløpe).
Dette består tydeligvis av to indekser:
Accentsconagua
no-cache har blitt sattpost-sjekk og de pre-sjekk intervallet som utløpt, vil en nyere versjon av dataene bli forespurt; Ellers vil en bufret versjon hentes.Dette bestemte aspektet av caching er utenfor omfanget av denne serien, så mye mer kan skrives og forklares; Definisjonen ovenfor bør imidlertid være tilstrekkelig til å forklare topptekstene du ser.
Denne headerverdien ligner Cache-Control header ved at den forteller at servere skal behandle lignende, påfølgende forespørsler.
Generelt vil dette instruere serveren om en cache-respons kan brukes, eller en ny verdi må hentes. Dette er et annet element som kan bli for komplisert, men for å forsøke å destillere forklaringen til noe som er litt mer i tråd med det vi diskuterer, kan varierehodeelementet også instruere serveren på de ulike innholdstyper som klient kan behandle.
Så i eksemplet ovenfor instruerer vi serveren at klienten vår er i stand til å kunne behandle kodet informasjon.
Innholdslengde er et enkelt konsept med en enkelt gotcha: Først definerer det bare lengden på responsens kropp.
Saken er, det gjør det i 8-bit byte. Dette betyr at svaret ikke er oppgitt i kilobytes, megabyte eller hvilken form for data vi vanligvis ser på.
Til dette formål må du kanskje utføre litt konvertering hvis du ønsker å samle mer rik informasjon om dataene som returneres.
Tilkoblingsverdien angir hvilken type tilkobling den forespørrende nettleseren foretrekker. Ovenfor ser vi at verdien er definert som "nær", noe som betyr at når svaret er sendt, kan forbindelsen lukkes.
Det er imidlertid andre alternativer. For eksempel kan du motta "keep-alive" som åpenbart vil holde forbindelsen levende i en viss tid.
Igjen, dette er et annet eksempel på noe som ville kreve sin egen artikkel for fullt å diskutere; Dette gir imidlertid innsikt i hvilken type tilkobling serveren foretrekker som kan hjelpe deg med å konstruere fremtidige forespørsler.
Dette er egentlig bare relevant for begge POST og TRYKK forespørsler. Kort sagt, dette definerer kroppstypen av forespørslene.
Dette kan variere basert på dataene som sendes. Noen ganger kan det være en kodet URL, noen ganger kan det være PHP, noen ganger kan det være noe annet. Uansett, dette bidrar til å sikre at vi kan kontrollere at dataene som kommer tilbake i innholdet, er i tråd med det vi forventer gitt vår forespørsel.
Kroppselementet inneholder faktisk informasjonen som returneres fra serveren.
I vårt eksempel fra to artikler siden mottok vi en JSON-streng fra Twitter. I eksemplet ovenfor mottar vi en enkel tekststreng. Til slutt kan svaret komme tilbake som en form for binær data som vil trenge et nivå av de-serialisering.
Uansett er det opp til oss som implementatorer av forespørselen å vite hvordan du skal dekode responsen ordentlig før du viser den til brukerne.
Svaret refererer faktisk til HTTP-responskoden som sendes fra serveren tilbake til den forespørgende klienten. Hvis du ikke er kjent med HTTP-statuskoder, anbefaler jeg at du sjekker ut HTTPStat.us for en veldig god referanse.
Kort sagt, et svar består av en numerisk kode og en tekstbasert melding for å indikere resultatet av forespørselen.
I eksemplet ovenfor kan du se at vi har mottatt statusen "200" og "OK" -meldingen. Koden og meldingsparet skal alltid være synkronisert med hverandre.
Dette betyr at hvis du mottar en '403', bør du også motta en 'Forbidden', eller hvis du mottar en '404', bør du motta en 'ikke funnet' melding.
Personlig har jeg funnet disse verdiene for å være viktig for å diagnostisere når problemer har gått galt med forespørsler jeg har laget.
Til slutt refererer cookie-gruppen til all informasjon som er sendt over ledningen basert på informasjonskapsler som eksisterer mellom den nåværende klienten og serveren som kommuniserer.
Avhengig av arten av forespørselen din, kan dette eller ikke være tomt - dette varierer for mye fra tilfelle til tilfelle for å gi en endelig veiledning. Kort sagt, hvis det ikke er etablert noen informasjonskapsler mellom de to forbindelsene, vil dette trolig alltid være tomt. Ellers vil dataene som består av cookie-arrayet, være spesielt basert på informasjonskapslene som eksisterer mellom de to tjenestene.
Totalt sett er det en god del data og det vil varierer fra forespørsel til forespørsel basert på hva du ber om å motta og basert på serverens svar; Men det er det du nå vet hva å forvente og hvordan man skal håndtere alle tilfeller.
Hvis verre blir verre i arbeidet ditt, kan du alltid bruke en debugger eller bare plassere noen debug-setninger, for eksempel print_r eller var_dump for å se hva serveren kommer tilbake, slik at du kan grasiøst håndtere feilene.
Senere vil vi se på WordPress HTTP API for å undersøke andre metoder som wp_remote_post og wp_remote_request slik at vi får et komplett bilde av HTTP API.
Inntil da har denne serien forhåpentligvis gitt deg så mye grundig dekning av wp_remote_get for å hjelpe ikke bare med å forbedre arbeidet ditt, men også å pique din nysgjerrighet om hva som er mulig når det kommer til eksterne forespørsler.
