Flash Sale! Up to 40% off on unlimited courses, tutorials and creative asset downloads Up to 40% off on unlimited assets SAVE NOW
Advertisement
  1. Code
  2. Web Development
Code

HTTP Ringkas: Pesan HTTP

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Resources
HTTP Succinctly: HTTP Connections

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

Dalam bab ini, kita akan melihat ke dalam pesan yang dipertukarkan dalam transaksi HTTP. Kita akan belajar tentang jenis pesan, header HTTP, dan kode status. Memahami apa yang ada di dalam pesan HTTP sangat penting bagi developer yang bekerja di web. Anda tidak hanya akan membangun aplikasi yang lebih baik dengan menanggapi dengan jenis pesan yang tepat, tetapi Anda juga dapat menemukan masalah dan masalah debug ketika aplikasi web tidak berfungsi.


Permintaan dan Tanggapan

Bayangkan berjalan ke orang asing di bandara dan bertanya, 'Apakah Anda tahu jam berapa sekarang?' Agar orang asing itu menanggapi dengan waktu yang tepat, beberapa hal harus ada. Pertama, orang asing harus memahami pertanyaan Anda, karena jika dia tidak tahu bahasa Inggris, dia mungkin tidak dapat memberikan tanggapan. Kedua, orang asing itu membutuhkan akses ke jam tangan atau alat pengatur waktu lainnya.

Analogi bandara ini mirip dengan cara kerja HTTP. Anda, klien, membutuhkan sumber daya dari pihak lain (sumber informasi tentang waktu hari). Jadi, Anda membuat permintaan ke pihak lain menggunakan bahasa dan kosakata yang Anda harap pihak lain akan mengerti. Jika pihak lain memahami permintaan Anda dan memiliki sumber daya yang tersedia, itu dapat membalas. Jika mengerti permintaan tersebut tetapi tidak memiliki sumber daya, ia masih dapat merespons dan memberi tahu Anda bahwa itu tidak diketahui. Jika pihak lain tidak memahami apa yang Anda katakan, Anda mungkin tidak mendapatkan tanggapan apa pun.

HTTP adalah permintaan dan tanggapan protokol. Klien mengirim permintaan HTTP ke server menggunakan pesan yang diformat dengan hati-hati yang akan dimengerti oleh server. Server merespons dengan mengirim respons HTTP yang akan dimengerti klien. Permintaan dan respons adalah dua jenis pesan berbeda yang dipertukarkan dalam satu transaksi HTTP. Standar HTTP menentukan apa yang masuk ke dalam pesan permintaan dan tanggapan ini, sehingga setiap orang yang berbicara 'HTTP' akan saling memahami dan dapat bertukar sumber daya (atau ketika sumber daya tidak ada, server masih dapat membalas dan memberi tahu Anda).


Permintaan Mentah dan Tanggapan

Browser web tahu cara mengirim permintaan HTTP dengan membuka koneksi jaringan ke mesin server dan mengirim pesan HTTP sebagai teks. Tidak ada yang ajaib tentang permintaan-itu hanya perintah dalam teks ASCII biasa dan diformat sesuai dengan spesifikasi HTTP. Setiap aplikasi yang dapat mengirim data melalui jaringan dapat membuat permintaan HTTP. Anda bahkan dapat membuat permintaan manual menggunakan aplikasi seperti Telnet dari baris perintah. Sesi Telnet yang normal menghubungkan melalui port 23, tetapi seperti yang kita pelajari di bab pertama, port jaringan default untuk HTTP adalah port 80.

Gambar berikut adalah screenshot dari sesi Telnet yang terhubung ke odetocode.com pada port 80, membuat permintaan HTTP, dan menerima respons HTTP.

Figure 2: Making an HTTP request
Membuat permintaan HTTP

Sesi Telnet dimulai dengan mengetik:

Harap dicatat bahwa klien Telnet tidak diinstal secara default pada Windows 7, Windows Server 2008 R2, Windows Vista, atau Windows Server 2008. Anda dapat menginstal klien dengan mengikuti prosedur yang tercantum di http://technet.microsoft.com/en-us/library/cc771275(v=ws.10).aspx.

Perintah ini memberitahu sistem operasi untuk meluncurkan aplikasi Telnet, dan memberitahu aplikasi Telnet untuk terhubung ke www.odetocode.com pada port 80.

Setelah Telnet terhubung, kita dapat mengetikkan pesan permintaan HTTP. Baris pertama dibuat dengan mengetik teks berikut lalu menekan Enter:

Informasi ini akan memberitahu server kami ingin mengambil sumber daya yang terletak di '/' (yaitu sumber daya root atau home page), dan kami akan menggunakan fitur HTTP 1.1. Baris berikutnya kita ketik ini:

Informasi host ini adalah bagian informasi yang diperlukan dalam pesan permintaan HTTP 1.1. Alasan teknis untuk melakukan ini adalah membantu server yang mendukung banyak situs web, yaitu www.odetocode.com dan www.odetofood.com dapat dihosting di server yang sama, dan informasi host dalam pesan akan membantu server web mengarahkan permintaan ke aplikasi web yang tepat.

Setelah mengetik dua baris sebelumnya, kita dapat menekan Enter dua kali untuk mengirim pesan ke server. Apa yang Anda lihat selanjutnya di jendela Telnet adalah respons HTTP dari server web. Kami akan membahas lebih detail nanti, tetapi tanggapan mengatakan bahwa sumber daya yang kami inginkan (laman beranda default dari www.odetocode.com), telah dipindahkan. Ini telah pindah ke lokasi odetocode.com. Terserah klien sekarang untuk mem-parsing pesan respons ini dan mengirim permintaan ke odetocode.com bukan www.odetocode.com jika ingin mengambil halaman beranda. Web browser akan pergi ke lokasi baru secara otomatis.

Jenis 'pengalihan' ini umum, dan dalam skenario ini alasannya adalah untuk memastikan semua permintaan sumber daya dari OdeToCode melalui odetocode.com dan bukan www.odetocode.com (ini adalah pengoptimalan mesin telusur yang dikenal sebagai kanonikalisasi URL) .

Sekarang setelah kami melihat permintaan dan respons HTTP mentah, mari gali bagian-bagian tertentu.


Metode permintaan HTTP

Kata GET yang diketikkan ke dalam sesi Telnet adalah salah satu metode HTTP utama. Setiap pesan permintaan harus menyertakan salah satu metode HTTP, dan metode ini memberi tahu server apa yang ingin dilakukan oleh permintaan. HTTP GET ingin mendapatkan, mengambil, dan mengambil sumber daya. Anda bisa GET gambar (GET /logo.png), atau GET file PDF, (GET /documents/report.pdf), atau sumber daya yang dapat diambil lainnya yang mungkin dimiliki server. Daftar operator HTTP umum ditunjukkan dalam tabel berikut.

Metode Deskripsi
GET Mengambil sumber daya
PUT Menyimpan sumber daya
DELETE Hapus sumber daya
POST Perbarui sumber daya
HEAD Ambil header untuk sumber daya

Dari kelima metode ini, hanya dua yang merupakan workorses utama dari web: GET dan POST. Browser web mengeluarkan permintaan GET saat ingin mengambil sumber daya, seperti halaman, gambar, video, atau dokumen. GET permintaan adalah jenis permintaan yang paling umum.

Browser web mengirim permintaan POST saat ia memiliki data untuk dikirim ke server. Misalnya, mengklik 'Tambahkan ke Keranjang' di situs seperti amazon.com akan POST informasi ke Amazon tentang apa yang ingin kita beli. Permintaan POST biasanya dihasilkan oleh <form> pada halaman web, seperti formulir yang Anda isi dengan <input> elemen untuk alamat dan informasi kartu kredit.


GET and Safety

Ada bagian dari spesifikasi HTTP yang berbicara tentang metode HTTP 'safe'. Metode safe, seperti namanya, jangan melakukan sesuatu yang 'tidak aman' seperti menghancurkan sumber daya, mengirimkan transaksi kartu kredit, atau membatalkan akun. Metode GET adalah salah satu metode yang aman karena itu hanya harus mengambil sumber daya dan tidak mengubah keadaan sumber daya. Mengirim permintaan GET untuk gambar JPG tidak mengubah gambar, hanya mengambil gambar untuk ditampilkan. Singkatnya, tidak boleh ada efek samping terhadap permintaan GET.

HTTP POST bukan metode yang aman. POST biasanya mengubah sesuatu di server - ia memperbarui akun, mengirim pesanan, atau melakukan operasi khusus lainnya. Browser web biasanya memperlakukan GET dan POST secara berbeda karena GET aman dan POST tidak aman. Tidak apa-apa untuk menyegarkan halaman web yang diambil oleh permintaan GET browser web hanya akan menerbitkan ulang permintaan GET terakhir dan merender apa pun yang dikirim oleh server. Namun, jika halaman yang kita lihat di browser adalah respons dari permintaan HTTP POST, browser akan memperingatkan kita jika kita mencoba me-refresh halaman. Mungkin Anda pernah melihat jenis peringatan ini di browser web Anda.

Figure 3: Refreshing a POST request
Menyegarkan permintaan POST

Karena peringatan seperti ini, banyak aplikasi web yang selalu berusaha membuat klien melihat hasil permintaan GET. Setelah pengguna mengklik tombol untuk POST informasi ke server (seperti mengirim pesanan), server akan memproses informasi dan merespons dengan pengalihan HTTP (seperti pengalihan yang kita lihat di jendela Telnet) yang memberi tahu browser untuk GET sumber daya lainnya. Browser akan mengeluarkan permintaan GET, server akan merespon dengan 'terima kasih atas pesanan' sumber daya, dan kemudian pengguna dapat menyegarkan atau mencetak halaman dengan aman sebanyak yang dia mau. Ini adalah pola desain web umum dikenal sebagai pola POST/Redirect/GET.

Sekarang setelah kita tahu sedikit tentang POST dan GET, mari kita bicara tentang beberapa skenario umum dan melihat kapan menggunakan metode yang berbeda.


Skenario-GET Umum

Katakanlah Anda memiliki halaman dan ingin pengguna untuk mengklik tautan untuk melihat artikel pertama dalam seri ini. Dalam hal ini, hyperlink sederhana adalah yang Anda butuhkan.

Ketika seorang pengguna mengklik pada hyperlink di browser, browser mengeluarkan permintaan GET ke URL yang ditentukan dalam atribut href dari tag anchor. Permintaan akan terlihat seperti ini:


Skenario-POST

Sekarang bayangkan Anda memiliki halaman di mana pengguna harus mengisi informasi untuk membuat akun. Mengisi informasi memerlukan tag <input> , dan kami mengumpulkan input ini di dalam tag <form> dan memberi tahu browser tempat mengirimkan informasi.

Ketika pengguna mengklik tombol kirim, browser menyadari tombol yang ada di dalam form. Form ini memberi tahu browser bahwa metode HTTP yang digunakan adalah POST, dan jalur ke POST adalah /account/create. Permintaan HTTP sebenarnya membuat browser akan terlihat seperti ini.

Perhatikan input form disertakan dalam pesan HTTP. Ini sangat mirip dengan bagaimana parameter muncul di URL, seperti yang kita lihat di artikel sebelumnya. Terserah aplikasi web yang menerima permintaan ini untuk menguraikan nilai-nilai tersebut dan membuat akun pengguna. Aplikasi kemudian dapat merespon dengan berbagai cara, tetapi ada tiga tanggapan umum:

  1. Respon dengan HTML yang memberi tahu pengguna bahwa akun telah dibuat. Melakukannya akan membuat pengguna melihat hasil permintaan POST, yang dapat menyebabkan masalah jika dia me-refresh halaman-itu mungkin mencoba untuk mendaftar mereka untuk kedua kalinya!
  2. Respon dengan instruksi pengalihan seperti yang kita lihat sebelumnya agar browser mengeluarkan permintaan GET yang aman untuk laman yang memberi tahu pengguna bahwa akun telah dibuat.
  3. Menanggapi dengan eror, atau mengarahkan ke halaman eror. Kita akan melihat skenario eror sedikit lebih lama di buku ini.

Form dan permintaan GET

Skenario yang ketiga adalah skenario pencarian. Dalam skenario pencarian, Anda memerlukan  <input> agar pengguna memasukkan istilah pencarian. Ini mungkin terlihat seperti berikut.

Melihat metode pada form ini GET, bukan POST. Itu karena pencarian adalah operasi pengambilan yang aman, tidak seperti membuat akun atau memesan penerbangan ke Belgia. Browser akan mengumpulkan input dalam form dan mengeluarkan permintaan GET ke server:

Perhatikan bukannya menempatkan nilai input ke dalam isi pesan, input masuk ke bagian string kueri dari URL. Browser mengirimkan permintaan GET untuk /search?term=love. Karena istilah pencarian ada di URL, pengguna dapat menandai URL atau menyalin tautan dan mengirimkannya dalam email. Pengguna juga dapat menyegarkan halaman sebanyak yang diinginkannya, sekali lagi karena operasi GET untuk hasil pencarian adalah operasi yang aman yang tidak akan merusak atau mengubah data.


Sebuah Kata tentang Metode dan Sumber Daya

Kami telah berbicara sedikit tentang sumber daya sebagai sumber daya fisik pada sistem file server. Cukup sering, sumber daya seperti file PDF, file video, file gambar, dan file skrip memang ada sebagai file fisik di server. Namun, URL yang menunjuk ke dalam banyak aplikasi web modern tidak benar-benar mengarah ke file. Teknologi seperti ASP.NET dan Ruby on Rails akan mencegat permintaan untuk sumber daya dan menanggapi apa pun yang mereka mau. Mereka mungkin membaca file dari database dan mengembalikan konten dalam respons HTTP untuk membuatnya tampak seolah-olah sumber daya benar-benar ada di server itu sendiri.

Contoh yang bagus adalah contoh POST yang kami gunakan sebelumnya yang menghasilkan permintaan ke /account/create. Kemungkinan tidak ada file asli bernama 'create' di direktori 'account'. Sebaliknya, sesuatu di server web mengambil permintaan ini, membaca dan memvalidasi informasi pengguna, dan membuat catatan dalam database. Sumber daya vitual /account/create dan tidak ada. Namun, semakin Anda dapat memikirkan sumber daya virtual sebagai sumber daya nyata, semakin baik arsitektur aplikasi dan desain Anda akan mengikuti kekuatan HTTP.


Permintaan HTTP Header

Sejauh ini kami telah melihat permintaan HTTP mentah dan berbicara tentang dua metode populer HTTP GET dan POST. Tapi seperti yang ditunjukkan Telnet, ada lebih banyak pesan permintaan HTTP daripada hanya metode HTTP. Pesan permintaan HTTP yang lengkap terdiri dari bagian berikut:

Pesan selalu dalam teks ASCII, dan garis mulai selalu berisi metode, URL, dan versi HTTP (paling sering 1.1, yang sudah ada sejak 1999). Bagian terakhir, Bagian tubuh, dapat berisi data seperti parameter akun masuk yang kita lihat sebelumnya. Ketika meng-upload file, Bagian tubuh dapat menjadi cukup besar.

Bagian tengah, bagian di mana kita melihat Host: odetocode.com, berisi satu atau lebih header HTTP (ingat, di host HTTP 1.1 adalah header yang diperlukan). Header berisi informasi yang berguna yang dapat membantu server memproses permintaan. Sebagai contoh, dalam artikel terakhir kita berbicara tentang representasi sumber daya dan bagaimana klien dan server dapat bernegosiasi tentang representasi terbaik dari suatu sumber daya (negosiasi konten). Jika klien ingin melihat sumber daya dalam bahasa Prancis, misalnya, ia dapat menyertakan entri header (header Accept-Language) yang meminta konten Prancis.

Ada berbagai header yang didefinisikan oleh spesifikasi HTTP. Beberapa header adalah header umum yang dapat muncul baik dalam permintaan atau pesan respons. Contohnya adalah header Date. Klien atau server dapat mencakup header Date menunjukkan ketika ia membuat pesan.

Semuanya tetapi header host adalah opsional, tetapi ketika header muncul harus mematuhi standar. Misalnya, spesifikasi HTTP mengatakan nilai header date harus dalam format RFC822 untuk tanggal.

Beberapa header permintaan yang lebih populer muncul di tabel berikut.

Header Deskripsi
Referer Ketika pengguna mengklik pada link, klien dapat mengirim URL laman rujukan dalam header ini.
User-Agent Informasi mengenai user agent (software) membuat permintaan. Banyak aplikasi menggunakan informasi di header ini, ketika ada, untuk mencari tahu apa yang membuat browser meminta (Internet Explorer 6 versus Internet Explorer 9 versus Chrome, dll.).
Accept Menjelaskan jenis media yang user agent yang bersedia menerima. Header ini digunakan untuk negosiasi konten.
Accept-Language Menjelaskan bahasa yang disukai agen pengguna.
Cookie Berisi informasi cookie, yang akan kita lihat di bab selanjutnya. Informasi cookie umumnya membantu melacak server atau mengidentifikasi pengguna.
If-Modified-Since Akan berisi tanggal ketika agen pengguna terakhir mengambil (dan cache) sumber daya. Server hanya perlu mengirim kembali seluruh sumber daya jika sudah dimodifikasi sejak saat itu.

Permintaan HTTP lengkap mungkin terlihat seperti berikut ini.

Seperti yang Anda lihat, beberapa header berisi beberapa nilai, seperti header Accept. Header Accept adalah daftar jenis MIME yang suka dilihat, termasuk HTML, XHTML, XML, dan akhirnya */* (artinya saya suka HTML yang terbaik, tetapi Anda dapat mengirimi saya apa saja (*/*) dan saya akan mencoba untuk cari tahu).

Juga perhatikan penampilan "q" di beberapa header. Nilai q selalu berupa angka dari 0 hingga 1 dan mewakili nilai kualitas atau 'tingkat preferensi relatif' untuk nilai tertentu. Standarnya adalah 1.0, dan angka yang lebih tinggi menunjukkan preferensi yang lebih tinggi.


Respons

Respons HTTP memiliki struktur yang mirip dengan permintaan HTTP. Bagian-bagian respons adalah:

Respons HTTP lengkap untuk permintaan lengkap terakhir yang kami cantumkan mungkin terlihat seperti ini (dengan sebagian besar HTML dihilangkan karena singkatnya).

Baris pembuka permintaan dimulai dengan versi HTTP, dan kemudian kode status dan alasan yang sangat penting.


Kode Status Respon

Kode status adalah angka yang ditentukan oleh spesifikasi HTTP dan semua angka masuk ke dalam salah satu dari lima kategori.

Range Kategori
100-199 Informasi
200-299 Keberhasilan
300-399 Pengalihan
400-499 Eror Klien
500-599 Eror Server

Meskipun kami tidak akan merinci semua kode status HTTP yang mungkin, tabel berikut akan merinci kode yang paling umum.

Kode Alasan Deskripsi
200 OK Kode status yang semua orang ingin melihat. Sebuah 200 kode dalam respon berarti semua bekerja!
301 Moved Permanently Sumber daya telah dipindahkan ke URL yang ditentukan di header Location dan klien tidak perlu memeriksa kembali URL ini.

Kami melihat contoh ini sebelumnya ketika kami menggunakan Telnet dan server mengarahkan kami dari www.odetocode.com ke odetocode.com untuk memberikan mesin pencari URL kanonik.
302 Moved Temporarily Sumber daya yang telah pindah ke URL yang ditetapkan di header Location. Di masa depan, klien masih dapat meminta URL karena itu adalah langkah sementara.

Jenis kode respons ini biasanya digunakan setelah operasi POST untuk memindahkan klien ke sumber daya yang dapat diambil dengan GET (pola POST/Redirect/GET yang telah kita bahas sebelumnya).
304 Not Modified Ini adalah server yang memberi tahu klien bahwa sumber daya tidak berubah sejak terakhir kali klien mengambil sumber daya, sehingga hanya dapat menggunakan salinan cache lokal.
400 Bad Request Server tidak bisa mengerti permintaan. Permintaan mungkin menggunakan sintaks yang salah.
403 Forbidden Server menolak akses ke sumber daya.
404 Not Found Populer kode berarti sumber tidak ditemukan.
500 Internal Server Error Server mengalami kesalahan dalam memproses permintaan. Sering terjadi karena eror pemrograman dalam aplikasi web.
503 Service Unavailable Server saat ini tidak akan melayani permintaan. Kode status ini dapat muncul ketika server menghambat permintaan karena itu di bawah beban berat.

Kode status respons merupakan bagian yang sangat penting dari pesan HTTP karena mereka memberi tahu klien apa yang terjadi (atau dalam kasus pengalihan, ke mana harus pergi berikutnya).


Kode Status HTTP Versus Aplikasi Anda

Ingat bahwa kode status HTTP adalah kode untuk menunjukkan apa yang terjadi pada level HTTP. Ini tidak selalu mencerminkan apa yang terjadi dalam aplikasi Anda. Misalnya, bayangkan pengguna mengirimkan formulir masuk ke server, tetapi tidak mengisi bidang Nama Terakhir. Jika aplikasi Anda membutuhkan nama belakang, itu akan gagal untuk membuat akun untuk pengguna. Ini tidak berarti Anda harus mengembalikan kode eror HTTP yang mengindikasikan kegagalan. Anda mungkin ingin hal sebaliknya terjadi - Anda ingin berhasil mengembalikan beberapa konten ke klien dengan kode status 200 (OK). Konten akan memberi tahu pengguna bahwa nama belakang tidak diberikan. Dari perspektif aplikasi permintaan itu gagal, tetapi dari perspektif HTTP permintaan itu berhasil diproses. Ini normal dalam aplikasi web.


Header Respons

Respons mencakup informasi header yang memberikan metadata klien yang dapat digunakan untuk memproses respons. Misalnya, jenis konten akan ditentukan sebagai jenis MIME, seperti yang kita bicarakan di artikel terakhir. Dalam tanggapan berikut kita dapat melihat tipe konten adalah HTML, dan set karakter yang digunakan untuk menyandikan jenisnya adalah UTF-8. Header juga dapat berisi informasi tentang server, seperti nama perangkat lunak dan versinya.

Header respons yang muncul sering akan tergantung pada jenis respons. Misalnya, respons pengalihan perlu menyertakan header Location yang memberi tahu klien ke mana harus pergi berikutnya.

Ada sejumlah header yang dikhususkan untuk cache dan optimalisasi kinerja. ETag, Expires, dan Last-Modified semua memberikan informasi tentang cacheability respons. ETag adalah pengenal yang akan berubah ketika sumber daya mendasar berubah, jadi membandingkan ETag adalah cara yang efisien untuk mengetahui apakah sesuatu perlu disegarkan. Header Expires memberitahu klien berapa lama cache sumber daya tertentu. Kami akan kembali dan melihat caching lebih detail nanti.


Di mana kita?

Dalam bab ini, kami telah belajar bahwa pesan HTTP selalu berpasangan. Pertama ada permintaan, dan kemudian ada respons. Informasi dalam pesan-pesan ini semuanya dalam teks yang dapat dibaca, dan ada banyak alat yang dapat Anda gunakan untuk memeriksa permintaan HTTP yang dibuat pada mesin Anda. Fiddler adalah salah satu alat seperti itu jika Anda menjalankan Windows (http://fiddler2.com). Ini mudah digunakan, dan Anda dapat melihat permintaan HTTP mentah yang dibuat, termasuk semua header.

Pesan adalah tentang memastikan kedua belah pihak dalam transaksi memahami apa yang mereka terima. Baris pertama dari pesan HTTP selalu eksplisit tentang maksudnya. Dalam pesan permintaan, URL dan metode HTTP muncul terlebih dahulu untuk mengidentifikasi apa yang harus terjadi pada sumber daya tertentu. Sebagai respons, kode status akan menunjukkan bagaimana permintaan diproses. Kami juga memiliki header yang bergerak di kedua arah yang memberikan lebih banyak informasi tentang permintaan dan respons. Di bab berikutnya kita akan belajar lebih banyak tentang bagaimana pesan-pesan ini melintasi jaringan.

Advertisement
Advertisement
Advertisement
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.