7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
Advertisement
  1. Code
  2. Creative Coding

Melihat HTTP HTTP API: wp_remote_get - Respon

Scroll to top
Read Time: 8 mins
This post is part of a series called A Look at the WordPress HTTP API.
A Look at the WordPress HTTP API: A Practical Example of wp_remote_get
A Look at the WordPress HTTP API: wp_remote_get - the Arguments

Indonesian (Bahasa Indonesia) translation by Rossie (you can also view the original English article)

Dalam seri ini, kita telah melihat fungsi HTTP API wp_remote_get WordPress untuk memahami cara kerjanya, bagaimana kita dapat menggunakannya, dan argumen opsional yang diterima.

Dari sini, kita dapat menulis permintaan mendetail; Namun, itu hanya setengah dari itu - ada juga responsnya.

Di artikel kedua, kita melihat apa respon dasar yang akan terlihat, bagaimana mengevaluasinya, dan bagaimana menampilkannya di layar, tetapi kita sebenarnya tidak berbicara tentang respon secara detail.

Jika Anda ingin menulis lebih banyak permintaan lanjutan dan menulis lebih banyak kode defensif, maka penting untuk memahami data yang dikirim sebagai tanggapan. Dalam artikel terakhir ini, kita akan melakukan hal itu.


Lihat Tanggapan

Pertama, penting untuk memahami apa yang saya maksud dengan menulis kode defensif: Ketika menulis perangkat lunak, kita sering harus bekerja dengan kasus-kasus bahwa pengguna dapat melakukan sesuatu yang salah, input mungkin diset secara tidak benar, atau data dapat diambil atau diterima - seperti dalam hal jawaban - tidak benar.

Untuk itu, kita mengkode defensif terhadap skenario tersebut sehingga software tidak benar-benar crash atau membombardir saat pengguna menggunakannya. Sebaliknya, ia gagal dengan anggun dan terus berlanjut.

Dengan mengetahui apa sebenarnya fungsi yang diterima sebagai tanggapan atas permintaannya, kita tahu data apa yang dicari, dan kemudian bagaimana menangani kasus dengan anggun ketika tidak kembali seperti yang kita harapkan.

Tanggapan Contoh

Untuk mengatur panggung untuk apa yang diharapkan, mari kita lihat contoh respon. Katakanlah Anda harus membuat permintaan GET ke URL yang akan mengembalikan sedikit teks sederhana kepada Anda.

Secara umum, Anda dapat mengharapkan untuk membuat permintaan yang lebih rumit di mana tanggapannya mungkin XML atau JSON atau yang lain; Namun, semua informasi itu akan diatur dalam indeks body dari array tanggapan. Jadi, jika Anda memahami apa yang diharapkan, Anda memahami cara mengatasinya.

Dengan demikian, ini adalah respons yang dapat Anda harapkan dari permintaan sederhana ke domain yang tidak menghasilkan apa pun kecuali teks biasa.

Tidak lebih dari sebuah array (atau, sebenarnya, sebuah array dari array). Tidak ada yang terlalu buruk, kan?

Mari kita tinjau setiap elemen respons secara detail.

Headers

Seperti yang dapat Anda katakan dari respons di atas, header sebenarnya terdiri dari susunan lain yang terdiri dari informasi lain.

Sebelum melihat setiap bagian informasi di atas, penting untuk memahami apa sebenarnya header itu. Singkatnya, header memberikan informasi tentang komunikasi permintaan/respons yang ada antara klien dan server.

Ada berbagai macam header yang dapat dikirim kembali (banyak di antaranya berada di luar cakupan artikel ini), tetapi semuanya membantu untuk mendapatkan informasi tidak hanya tentang permintaan, tetapi tentang server yang digunakan berkomunikasi.

Dengan itu, mari kita lihat setiap elemen header secara detail.

Tanggal

Jelas, ini adalah elemen yang sangat mudah dimengerti: Sederhananya, ini adalah tanggal dan waktu ketika pesan itu dikirim. Ini jelas termasuk hari, tanggal, dan waktu di Greenwich Mean Time yang merupakan standar waktu global.

Server

Elemen server mengacu pada jenis software yang menjalankan server. Lebih sering daripada tidak, Anda cenderung melihat Apache; namun, ada aplikasi server lain yang tersedia saat ini seperti IIS dan nginx yang akan datang.

X-Powered-By

X-Powered-By mengacu pada software server yang menjalankan transaksi komunikasi. Dalam kasus ini, kita melihat PHP yang berarti bahwa permintaan dikirim ke server yang menjalankan Apache dan PHP.

Ini mungkin tidak selalu demikian.

Misalnya, Anda mungkin akhirnya berkomunikasi dengan server yang menjalankan nginx dan Python, atau jenis software server lain yang menjalankan Ruby on Rails.

X-Server

Elemen respons khusus ini mengacu pada alamat IP server tempat permintaan dikirim. Saya jarang sekali perlu mengetahui informasi khusus ini; namun, jika Anda akhirnya mendapatkan respons yang tidak diharapkan meskipun fakta bahwa semua informasi lainnya terlihat dalam urutan, mungkin membantu untuk mengetahui apakah IP server cocok dengan apa yang Anda harapkan untuk domain tempat permintaan itu dikirim.

Expires

Setiap kali permintaan dibuat dan tanggapan dikirim, boleh dikatakan, responsnya memiliki batas waktu.

Lebih spesifik lagi, respons akan dianggap "basi" setelah jangka waktu tertentu. Tentunya, waktu di mana respons dianggap basi adalah ketika respons dikatakan telah kadaluwarsa.

Berapa lama tanggapan dianggap tidak basi berdasarkan konfigurasi server, tetapi stempel waktu memiliki format yang sama dengan tanggal permintaan.

Cache-Kontrol

Kontrol cache mengacu pada gagasan bahwa browser web (atau mekanisme cache lain yang ada di antara klien dan server) mungkin atau mungkin tidak dapat menggunakan respons pertama sebagai respons untuk permintaan di masa mendatang.

Sebagai contoh, jika server merespon dengan no-cache, maka itu berarti bahwa peramban mesin, server, atau software proxy atau mekanisme cache lainnya harus memperlakukan setiap respons sebagai respons baru. Jika, di sisi lain, no-cache tidak ditentukan, maka respons pertama mungkin satu-satunya tanggapan yang bisa Anda dapatkan (setidaknya sampai cache disetel kedaluwarsa).

Ini jelas terdiri dari dua indeks:

  1. Indeks pertama berisi apakah atau no-cache telah ditetapkan
  2. Indeks kedua berisi informasi jika data telah di-cache. Sederhananya, jika interval post-check dan pre-check berakhir, maka data versi yang lebih baru akan diminta; jika tidak, versi cache akan diambil.

Aspek khusus dari cache ini berada di luar ruang lingkup seri ini karena lebih banyak yang dapat ditulis dan dijelaskan; Namun, definisi di atas seharusnya cukup untuk membantu menjelaskan header yang Anda lihat.

Vary

Nilai header ini mirip dengan header Cache-Control di mana ia mengatakan meminta server bagaimana menangani permintaan serupa, selanjutnya.

Secara umum, ini akan menginstruksikan server apakah atau tidak respon cache dapat digunakan, atau nilai segar harus diambil. Ini adalah elemen lain yang dapat menjadi sangat rumit, tetapi untuk mencoba menyaring penjelasan menjadi sesuatu yang sedikit lebih dalam lingkup untuk apa yang kita diskusikan, elemen header bervariasi juga dapat menginstruksikan server pada berbagai jenis konten yang klien dapat memproses.

Jadi pada contoh di atas, kita menginstruksikan server bahwa klien kita mampu memproses informasi yang disandikan.

Content-Length

Konten-panjang adalah konsep sederhana dengan satu gotcha: Pertama, itu hanya mendefinisikan panjang tubuh respon.

Masalahnya, ia melakukannya dalam 8-bit byte. Ini berarti bahwa respons tidak disediakan dalam kilobyte, megabyte, atau bentuk data apa pun yang biasa kita lihat.

Untuk itu, Anda mungkin perlu melakukan beberapa konversi jika Anda ingin mengumpulkan lebih banyak informasi yang kaya tentang data yang dikembalikan.

Koneksi

Nilai koneksi menentukan jenis sambungan apa yang diinginkan oleh browser yang meminta. Di atas, kita melihat bahwa nilai didefinisikan sebagai "dekat" yang berarti bahwa setelah respons dikirim, koneksi dapat ditutup.

Namun, ada alternatif lain. Misalnya, Anda mungkin menerima "keep-alive" yang, jelas, ingin menjaga koneksi tetap hidup untuk beberapa waktu.

Sekali lagi, ini adalah contoh lain dari sesuatu yang akan membutuhkan artikelnya sendiri untuk sepenuhnya dibahas; Namun, ini tidak memberikan wawasan tentang jenis koneksi yang lebih disukai server yang dapat membantu Anda dalam membangun permintaan di masa mendatang.

Jenis konten

Ini benar-benar hanya relevan untuk permintaan POST dan PUSH. Singkatnya, ini mendefinisikan tipe tubuh dari permintaan.

Ini dapat bervariasi berdasarkan data yang dikirim. Kadang-kadang mungkin URL yang dikodekan, kadang-kadang mungkin PHP, kadang-kadang itu mungkin sesuatu yang lain. Apa pun itu, ini membantu memastikan bahwa kita dapat memeriksa bahwa data yang muncul di konten sesuai dengan apa yang diharapkan dari permintaan.

Tubuh

Elemen tubuh sebenarnya berisi informasi yang dikembalikan dari server.

Dalam contoh dari dua artikel yang lalu, kita menerima string JSON dari Twitter. Dalam contoh di atas, kita menerima string teks sederhana. Pada akhirnya, respons dapat kembali sebagai suatu bentuk data biner yang akan membutuhkan tingkat de-serialisasi.

Apapun masalahnya, terserah kepada kita sebagai pelaksana permintaan untuk mengetahui cara mendekode tanggapan dengan benar sebelum menampilkannya kepada pengguna.

Respon

Tanggapan sebenarnya mengacu pada kode respons HTTP yang dikirim dari server kembali ke klien yang meminta. Jika Anda tidak akrab dengan kode status HTTP, maka saya sarankan untuk memeriksa HTTPStat.us untuk referensi yang sangat bagus.

Singkatnya, tanggapan terdiri dari kode numerik dan pesan berbasis teks untuk menunjukkan hasil dari permintaan tersebut.

Kode & Pesan

Dalam contoh di atas, Anda dapat melihat bahwa kita telah menerima kode status '200' dan pesan 'OK'. Pasangan kode dan pesan harus selalu sinkron satu sama lain.

Ini berarti bahwa jika Anda menerima '403' maka Anda juga harus menerima 'Forbidden', atau jika Anda menerima '404' maka Anda akan menerima pesan 'tidak ditemukan'.

Secara pribadi, saya telah menemukan nilai-nilai khusus ini menjadi penting untuk mendiagnosis ketika masalah telah salah dengan permintaan yang saya buat.

Cookies

Akhirnya, larik cookie mengacu pada informasi apa pun yang dikirim melalui kawat berdasarkan cookie yang ada antara klien dan server saat ini yang membuat komunikasi.

Tergantung pada sifat permintaan Anda, ini mungkin atau mungkin tidak kosong - ini bervariasi terlalu banyak berdasarkan kasus per kasus untuk memberikan panduan definitif. Singkatnya, jika tidak ada cookie yang dibuat di antara kedua koneksi, maka kemungkinan ini akan selalu kosong; jika tidak, data yang terdiri dari susunan cookie akan secara khusus didasarkan pada cookie yang ada di antara kedua layanan tersebut.


Kesimpulan

Secara keseluruhan, ada cukup banyak data dan itu akan bervariasi dari permintaan untuk meminta berdasarkan apa yang Anda minta untuk menerima dan berdasarkan tanggapan server; Namun, masalahnya adalah Anda sekarang tahu apa yang diharapkan dan bagaimana menangani semua kasus dengan tepat.

Jika lebih buruk menjadi lebih buruk dalam pekerjaan Anda, Anda selalu dapat menggunakan debugger atau cukup tempatkan beberapa pernyataan debug, seperti print_r atau var_dump untuk melihat apa server kembali sehingga Anda dapat menangani kesalahan dengan anggun.

Nanti, kita akan meninjau kembali HTTP HTTP API untuk memeriksa metode lain seperti wp_remote_post dan wp_remote_request sehingga kita mendapatkan gambaran lengkap tentang API HTTP.

Sampai saat itu, seri ini akan memberikan Anda banyak liputan mendalam tentang wp_remote_get untuk membantu tidak hanya meningkatkan pekerjaan Anda, tetapi juga menyinggung keingintahuan Anda tentang apa lagi yang mungkin dilakukan jika menyangkut permintaan jarak jauh.

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.