En titt på WordPress HTTP API En kort oversikt over wp_remote_post

I den første serien på WordPress HTTP API, tok vi en titt på wp_remote_get. Nærmere bestemt tok vi en titt på følgende aspekter av API:

  • En undersøkelse av funksjonen
  • Et praktisk eksempel derav
  • Hvordan håndtere svaret
  • Og forstå argumentene for funksjonen

Vi skal fortsette serien på WordPress HTTP API, men vi skal gjøre oppmerksom på en annen metode for API: et: wp_remote_post.

Gjennom det neste settet av artikler skal vi ta en oversikt over funksjonen for å forstå hva funksjonen tilbyr og hvorfor det er nyttig, et praktisk eksempel på hvordan å implementere det i arbeidet vårt, samt hvordan man forstår funksjonene og svaret som kommer fra funksjonen.

Med det sagt, la oss begynne vår undersøkelse av funksjonen.


Eksterne forespørsler: En oppdatering

Hvis du ikke har fulgt med så langt, anbefaler jeg på det sterkeste å sjekke ut det første innlegget i serien for å forstå det grunnleggende om hvordan ber om arbeid.

Ærlig talt, POST forespørsler er ikke så forskjellige. Akkurat som forespørsler brukes vanligvis til å hente informasjon fra serveren, POST forespørsler er vanligvis ment å sende meldinger til serveren.

Men her er saken: begge protokollene er i stand til å sende data og mottar data, men her er en generell tommelfingerregel for hvordan jeg vanligvis nærmer GET og POST-forespørsler.

  • forespørsler er vanligvis vant til hente informasjon fra serveren, slik at et svar er forventet
  • POST forespørsler er vanligvis vant til sende informasjon til serveren, og selv om et svar ikke kan forventes, er det alltid hyggelig å vite om serveren mottok og behandlet svaret riktig eller ikke

Gjennom resten av artiklene i denne delen av serien, tar vi en titt på hvordan man skal håndtere begge sakene - det vil si hvordan man håndterer når det ikke gis svar og hvordan man skal håndtere når et svar er gitt.


Et sammendrag av hvordan forespørsler er gjort

Nå, når det gjelder forespørsler på servernivå - spesielt i PHP - blir de vanligvis laget med følgende to funksjoner (med mindre du bruker et tredjepartsbibliotek som ikke er omfattet av denne serien).

Selv om vi har dekket dem nærmere i første innlegg, vil jeg oppsummere dem her.

  • file_get_contents aksepterer en nettadresse som en parameter og vil returnere dataene som er forespurt eller en feil ved feil. Det er en relativt vanlig måte å hente data for eksterne forespørsler på.
  • cURL er et helt bibliotek (i stedet for funksjon) som gir full konfigurasjonsmuligheter for utviklere til å tilpasse seg deres behov. Det er mye å lære om dette biblioteket. Hvis du er en avansert utvikler, må du sjekke ut cURL.

For det meste er det enkelt å forstå hvordan forespørsler gjøres, men i hvilken grad du tilpasser hvordan forespørgene er gjort er helt betinget av hvilket alternativ du velger å bruke - det vil si, file_get_contents eller cURL.

Selvfølgelig er dette mer av PHP-måten å utføre forespørsler på, og selv om vi kanskje implementerer dette i noen av våre arbeid, avhengig av prosjektets art, er dette ikke nødvendigvis dekket av WordPress-måten å gjøre det på..

Faktisk er ovennevnte en kort oppdatering basert på tidligere innhold. Likevel er det viktig å forstå hvor vi kommer fra, hva som er tilgjengelig, og hvor vi er på vei.


Hvordan POST Forespørsler er gjort i WordPress

Som nevnt er notatene ovenfor langt nærmere relatert til PHP, så la oss ta en titt på POST forespørsler i forbindelse med WordPress.

Og hvis du er i ferd med å bygge prosjekter for WordPress eller produkter på toppen av WordPress, er det viktig å forstå APIene som er tilgjengelige for å sikre at du ikke mister noen form for funksjon eller funksjonalitet med en oppgradering til kjernen WordPress Application.

Så, akkurat som vi har sett på WordPress Coding Standards for å gjennomgå de beste metodene for å skrive WordPress-basert kode, skal vi se på APIene som er tilgjengelige for å skrive POST forespørsler ved hjelp av beste praksis.

Til det formål, skriv inn wp_remote_post.

Funksjonen godtar to argumenter:

  • Nettadressen som forespørselen skal gjøres til
  • En rekke argumenter som bidrar til å skreddersy forespørselen til serveren.

Selv om mangfoldet av argumenter kommer til å være litt utenfor omfanget av det vi skal gjøre i denne serien, er det viktig å forstå hva som er tilgjengelig, spesielt hvis du skal gjøre mer avansert arbeid i fremtiden:

  • metode refererer til hvilken metode som brukes til forespørselen. Vi bruker åpenbart POST gitt naturen til API-metoden.
  • pause er hvor lenge du er villig til å vente på forespørselen om å behandle før du gir opp. Standardverdien er fem sekunder, men dette kan reduseres eller økes basert på innholdet i søknaden din.
  • omdirigering høres ut som om det er nettadressen du vil omdirigere etter at forespørselen er fullført, ikke sant? I stedet er det en tidsenhet - i sekunder - å vente på omdirigering før du gir opp på forespørselen.
  • bruker agent tillater oss å kontrollere brukeragenten som sendes sammen med forespørselen. Vanligvis er dette WordPress og versionsnummer, men det er åpenbart tilpassbart.
  • blokkerer Kort sagt, hvis dette er satt til true, vil skriptet fortsette å utføres til noe er returnert fra serveren; ellers vil skriptet fortsette å fungere uten å holde opp resten av søknaden. Gitt, dette kommer på bekostning av potensielt å aldri få tilbake et svar, men avhengig av forholdene du bygger, kan dette være bra.
  • komprimere ble introdusert i WordPress 2.6 og lar deg sende kroppen til forespørselen i et komprimert format. Dette vil være utenfor omfanget av våre fremtidige artikler.
  • dekomprimere ligner på komprimere, bortsett fra at det er på slutten vår - hvis komprimerte data er mottatt, vil dette tillate oss å dekomprimere innholdet før det gjøres ytterligere arbeid eller behandling på det.
  • sslverify ble introdusert i WordPress 2.8 og er nyttig for scenarier der du må sjekke om en SSL-sertifisering er gyldig. Hvis det ikke er det, blir forespørselen nektet; Ellers er du god til å gå. Dette alternativet vil også være utenfor omfanget av dette settet av artikler.

Tydeligvis er det mange ting som er tilgjengelige. I de neste artiklene håper jeg å se nærmere på noen av disse, men først la oss se på et veldig enkelt, praktisk eksempel på bruk av API-funksjonen.


la oss POST en forespørsel

På dette punktet bør ting være klart nok, ikke sant? Ved hjelp av wp_remote_post bør være like enkelt som å bruke wp_remote_get så starter i neste artikkel, skal vi bare gjøre det.

Inntil da må du kontrollere at du har gjennomgått alle artiklene som følger opp til dette punktet, og vær så snill å legge igjen eventuelle kommentarer og / eller spørsmål til dette innlegget i kommentarene.

Neste opp, vi kommer til å fungere!