Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

HTTP Ringkas: Sumber Daya HTTP

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

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

HTTP adalah protokol yang memungkinkan kami membeli oven microwave dari Amazon.com, berkumpul kembali dengan teman lama di obrolan Facebook, dan menonton video kucing lucu di YouTube. HTTP adalah protokol di belakang World Wide Web. Ini memungkinkan server web dari pusat data di Amerika Serikat untuk mengirim informasi ke kafe internet di Australia, di mana seorang siswa muda dapat membaca halaman web yang menjelaskan dinasti Ming di China.

Dalam buku ini kita akan melihat HTTP dari perspektif pengembang perangkat lunak. Memiliki pemahaman yang kuat tentang HTTP dapat membantu Anda menulis aplikasi web dan layanan web yang lebih baik. Ini juga dapat membantu Anda mendebug aplikasi dan layanan ketika ada yang salah. Kami akan mencakup semua dasar-dasar termasuk sumber daya, pesan, koneksi, dan keamanan yang terkait dengan HTTP.

Kita akan mulai dengan melihat sumber daya.

Sumber daya

Mungkin bagian paling dikenal dari web adalah alamat HTTP. Ketika saya ingin menemukan resep untuk hidangan yang menampilkan brokoli, yang hampir tidak pernah, maka saya mungkin membuka browser web saya dan memasukkan http://food.com di bilah alamat untuk membuka situs web food.com dan mencari resep . Browser web saya memahami sintaks ini dan tahu itu perlu membuat permintaan HTTP ke server bernama food.com. Kita akan berbicara nanti tentang apa artinya 'membuat permintaan HTTP' dan semua rincian jaringan yang terlibat. Untuk sekarang, kita hanya ingin fokus pada alamat: http://food.com.


Penentu Sumber Daya

Alamat http://food.com adalah apa yang kita sebut URL-a uniform resource locator. Ini merupakan sumber daya tertentu di web. Dalam kasus ini, sumber daya adalah halaman home dari situs food.com. Sumber daya adalah hal-hal yang ingin saya interaksi dengan di web. Gambar, halaman, file, dan video adalah semua sumber daya.

Ada miliaran, bahkan triliunan, tempat untuk pergi di Internet-dengan kata lain, ada triliunan sumber daya. Setiap sumber daya akan memiliki URL yang bisa saya gunakan untuk menemukannya. http://news.google.com adalah tempat yang berbeda dari http://news.yahoo.com. Ini adalah dua nama yang berbeda, dua perusahaan berbeda, dua situs web berbeda, dan oleh karena itu dua URL berbeda. Tentu saja, juga akan ada URL yang berbeda di dalam situs web yang sama. http://food.com/recipe/broccoli-salad-10733/ adalah URL untuk laman dengan resep salad brokoli, sementara http://food.com/recipe/grilled-cauliflower-19710/ masih ada di food.com, tetapi merupakan sumber daya yang berbeda menggambarkan resep cauliflower.

Kami dapat memecah URL terakhir menjadi tiga bagian:

  1. http, Bagian sebelum ://, adalah apa yang kita sebut skema URL. Skema ini menjelaskan cara mengakses sumber daya tertentu, dan dalam hal ini ia memberi tahu browser untuk menggunakan protokol transfer hypertext. Nanti kita juga akan melihat skema yang berbeda, HTTPS, yang merupakan protokol HTTP aman. Anda mungkin mengalami skema lain juga, seperti FTP untuk protokol transfer file, dan mailto untuk alamat email.

    Semuanya setelah :// akan spesifik untuk skema tertentu. Jadi, URL HTTP hukum mungkin bukan merupakan surat resmi untuk URL - keduanya tidak dapat dipertukarkan (yang masuk akal karena mereka menggambarkan berbagai jenis sumber daya).

  2. Food.com adalah host. Nama host ini memberi tahu browser tentang nama komputer yang menghosting sumber daya. Komputer akan menggunakan Sistem Nama Domain (DNS) untuk menerjemahkan food.com ke alamat jaringan, dan kemudian ia akan tahu persis di mana mengirim permintaan untuk sumber daya. Anda juga dapat menentukan bagian host dari URL menggunakan alamat IP.
  3. /recipe/grilled-cauliflower-19710/ adalah URL path. Host food.com harus mengenali sumber daya khusus yang diminta oleh jalur ini dan merespons dengan tepat.

Terkadang URL akan mengarah ke file pada sistem file host atau hard drive. Misalnya, URL http://food.com/logo.jpg mungkin menunjuk ke gambar yang benar-benar ada di server food.com. Namun, sumber daya juga bisa dinamis. URL http://food.com/recipes/brocolli mungkin tidak merujuk ke file asli di server food.com. Sebagai gantinya, beberapa jenis aplikasi berjalan di host food.com yang akan mengambil permintaan itu dan membangun sumber daya menggunakan konten dari database. Aplikasi ini mungkin dibangun menggunakan ASP.NET, PHP, Perl, Ruby on Rails, atau beberapa teknologi web lain yang tahu bagaimana menanggapi permintaan yang masuk dengan membuat HTML untuk browser untuk ditampilkan.

Bahkan, hari-hari ini banyak situs web mencoba untuk menghindari apa pun nama file asli di URL mereka. Sebagai permulaan, nama file biasanya dikaitkan dengan teknologi spesifik, seperti .aspx untuk teknologi ASP.NET Microsoft. Banyak URL akan hidup lebih lama dari teknologi yang digunakan untuk menghosting dan melayani mereka. Kedua, banyak situs ingin menempatkan kata kunci ke dalam URL (seperti memiliki /recipe/broccoli/ di URL untuk resep brokoli). Memiliki kata kunci ini di URL adalah bentuk optimasi mesin pencari (SEO) yang akan memberi peringkat sumber daya yang lebih tinggi dalam hasil mesin pencari. Kata kunci deskriptif, bukan nama file, penting untuk URL hari ini.

Beberapa sumber juga akan mengarahkan browser untuk mengunduh sumber daya tambahan. Laman beranda food.com akan menyertakan gambar, file JavaScript, CSS, dan sumber daya lainnya yang semuanya akan digabungkan untuk menyajikan 'laman beranda' dari food.com.

Figure 1 foodcom home page

Home page food.com

Ports, Query Strings, and Fragments

Sekarang kita tahu tentang skema URL, host, dan jalur, mari kita juga melihat URL dengan nomor port:

Angka 80 menunjukkan nomor port yang digunakan host untuk mendengarkan permintaan HTTP. Nomor port default untuk HTTP adalah port 80, jadi Anda biasanya melihat nomor port ini dihapus dari URL. Anda hanya perlu menentukan nomor port jika server mendengarkan pada port selain port 80, yang biasanya hanya terjadi dalam testing, debugging, atau development environments. Mari kita lihat URL lain.

Semuanya setelah ? (tanda tanya) dikenal sebagai query. Kueri, juga disebut query string, berisi informasi untuk situs web tujuan untuk menggunakan atau menafsirkan. Tidak ada standar formal untuk bagaimana string kueri harus terlihat karena secara teknis ada aplikasi untuk menafsirkan nilai-nilai yang ditemukannya, tetapi Anda akan melihat sebagian besar string kueri yang digunakan untuk meneruskan pasangan name-value dalam nama form name1=value1&name2=value2.

Sebagai contoh:

Ada dua pasangan nama-nilai dalam contoh ini. Pasangan pertama memiliki nama 'first' dan nilai 'Scott'. Pasangan kedua memiliki nama 'terakhir' dengan nilai 'Allen'. Di URL kami sebelumnya (http://www.bing.com/search?q=broccoli), mesin pencari Bing akan melihat nama 'q' yang terkait dengan nilai 'broccoli'. Ternyata mesin Bing mencari nilai 'q' untuk digunakan sebagai istilah pencarian. Kita dapat menganggap URL sebagai URL untuk sumber daya yang mewakili hasil pencarian Bing untuk brokoli.

Akhirnya, satu lagi URL:

Bagian setelah tanda # itu dikenal sebagai fragment. Fragmennya berbeda dengan bagian lain yang telah kami lihat sejauh ini, karena tidak seperti jalur URL dan string kueri, fragmen tidak diproses oleh server. Fragmen hanya digunakan pada klien dan mengidentifikasi bagian tertentu dari sumber daya. Khususnya, fragmen biasanya digunakan untuk mengidentifikasi elemen HTML tertentu di halaman oleh ID elemen.

Browser web biasanya akan menyelaraskan tampilan awal halaman web sedemikian rupa sehingga bagian atas elemen yang diidentifikasi oleh fragmen berada di bagian atas layar. Sebagai contoh, URL http://odetocode.com/Blogs/scott/archive/2011/11/29/programming-windows-8-the-limlime-to-the-strange.aspxfeedback memiliki nilai fragmen 'feedback'. Jika Anda mengikuti URL, browser web Anda harus menggulir halaman ke bawah untuk menampilkan bagian umpan balik dari posting blog tertentu di blog saya. Browser Anda mengambil seluruh sumber daya (entri blog), tetapi memusatkan perhatian Anda ke bagian khusus-bagian feedback. Anda dapat membayangkan HTML untuk posting blog tampak seperti berikut (dengan semua konten teks dihilangkan):

Klien memastikan elemen dengan ID 'feedback' ada di bagian atas.

Jika kami mengumpulkan semua yang telah kami pelajari sejauh ini, kami tahu URL dipecah menjadi beberapa bagian berikut:


URL Encoding

Semua pengembang perangkat lunak yang bekerja dengan web harus menyadari masalah encoding karakter dengan URL. Dokumen resmi yang mendeskripsikan URL berusaha keras untuk membuat URL dapat digunakan dan dapat dioperasikan semudah mungkin. URL harus mudah dikomunikasikan melalui email karena dicetak pada stiker bumper dan ditempelkan ke Ford Windstar 2001. Karena alasan ini, standar Internet menentukan karakter tidak aman untuk URL. Misalnya, karakter ruang dianggap tidak aman karena karakter ruang dapat keliru muncul atau menghilang ketika URL dicetak dalam bentuk (apakah itu satu ruang atau dua spasi di kartu nama Anda?).

Karakter tidak aman lainnya termasuk tanda angka (#) karena digunakan untuk membatasi fragmen, dan tanda sisipan (^) karena tidak selalu ditransmisikan dengan benar melalui semua perangkat jaringan. Bahkan, RFC 3986 ('hukum' untuk URL), mendefinisikan karakter yang aman untuk URL menjadi karakter alfanumerik di AS-ASCII, ditambah beberapa karakter khusus seperti titik dua (:) dan tanda garis miring (/).

Untungnya, Anda masih dapat mengirim karakter yang tidak aman dalam URL, tetapi semua karakter yang tidak aman harus di percent-encoded (alias URL yang di-encode). %20  adalah encoding untuk karakter spasi (di mana 20 adalah nilai heksadesimal untuk karakter ruang AS-ASCII).

Sebagai contoh, misalkan Anda ingin membuat URL untuk file bernama "^my resume.txt" pada someserver.com. URL yang legal dan encoded akan terlihat seperti:

Baik ^ dan karakter ruang telah percent-encoded. Sebagian besar kerangka aplikasi web akan menyediakan API untuk encoding URL yang mudah. Di sisi server, Anda harus menjalankan URL yang dibuat secara dinamis melalui API encoding hanya jika salah satu karakter tidak aman muncul di URL.


Sumber daya dan Tipe Media

Sejauh ini kami fokus pada URL dan menyederhanakan semua yang lain. Tapi, apa artinya ketika kita memasukkan URL ke browser? Biasanya itu berarti kita ingin mengambil atau melihat beberapa sumber daya. Ada banyak sekali materi untuk dilihat di web, dan kemudian kami juga akan melihat bagaimana HTTP juga memungkinkan kami untuk membuat, menghapus, dan memperbarui sumber daya. Untuk sekarang, kita akan tetap fokus pada pengambilan.

Kami belum sangat spesifik tentang jenis sumber daya yang ingin kami ambil. Ada ribuan jenis sumber daya yang berbeda di web-gambar, dokumen hypertext, dokumen XML, video, audio, aplikasi yang dapat dieksekusi, dokumen Microsoft Word, dan banyak lagi.

Agar host dapat melayani sumber daya dengan benar, dan agar klien dapat menampilkan sumber daya dengan tepat, pihak-pihak yang terlibat harus spesifik dan tepat tentang jenis sumber daya. Apakah sumber daya adalah gambar? Apakah sumber daya adalah film? Kami tidak ingin browser web kami mencoba merender gambar PNG sebagai teks, dan kami tidak ingin mereka mencoba menafsirkan hypertext sebagai gambar.

Ketika host menanggapi permintaan HTTP, ia mengembalikan sumber daya dan juga menentukan jenis konten (juga dikenal sebagai jenis media) dari sumber daya. Kita akan melihat detail tentang bagaimana tipe konten muncul dalam pesan HTTP di bab berikutnya.

Untuk menentukan jenis konten, HTTP bergantung pada standar Multipurpose Internet Mail Extensions (MIME). Meskipun MIME pada awalnya dirancang untuk komunikasi email, HTTP menggunakan standar MIME untuk tujuan yang sama, yaitu melabeli konten sedemikian rupa sehingga klien akan tahu apa isi kontennya.

Misalnya, ketika klien meminta halaman web HTML, tuan rumah dapat menanggapi permintaan HTTP dengan beberapa HTML yang diberi label sebagai 'teks/html'. Bagian 'text' adalah jenis media utama, dan 'html' adalah subtipe media. Saat menanggapi permintaan gambar, host akan memberi label sumber daya dengan jenis konten 'image/jpeg' untuk file JPG, 'image/gif' untuk file GIF, atau 'image/png' untuk file PNG. Jenis konten tersebut adalah jenis MIME standar dan secara harfiah apa yang akan muncul dalam respons HTTP.


Catatan Cepat tentang Ekstensi File

Anda mungkin berpikir bahwa browser akan bergantung pada ekstensi file untuk menentukan jenis konten dari sumber daya yang masuk. Misalnya, jika browser saya meminta 'frog.jpg', ia harus memperlakukan sumber daya sebagai file JPG, tetapi memperlakukan 'frog.gif' sebagai file GIF. Namun, untuk sebagian besar browser, ekstensi file adalah tempat terakhir yang akan digunakan untuk menentukan jenis konten yang sebenarnya.

Ekstensi file dapat menyesatkan, dan hanya karena kami meminta file JPG tidak berarti server harus merespon dengan data yang di encode dalam format JPG. Dokumen Microsoft Internet Explorer (IE) sebagai pertama kali melihat jenis konten yang ditentukan oleh host. Jika host tidak menyediakan tipe konten, IE akan memindai 200 byte pertama dari respons yang mencoba menebak jenis konten. Akhirnya, jika IE tidak menemukan tipe konten dan tidak dapat menebak jenis konten, IE akan jatuh kembali pada ekstensi file yang digunakan dalam permintaan sumber daya. Ini adalah salah satu alasan mengapa label jenis konten itu penting, tetapi jauh dari satu-satunya alasan.


Negosiasi Jenis Konten

Meskipun kami cenderung menganggap HTTP sebagai sesuatu yang digunakan untuk melayani laman web, ternyata spesifikasi HTTP menggambarkan protokol umum yang fleksibel untuk memindahkan informasi ketepatan tinggi. Bagian dari pekerjaan memindahkan informasi di sekitar adalah memastikan semua pihak yang terlibat tahu bagaimana menafsirkan informasi, dan inilah mengapa pengaturan jenis media penting.

Namun, jenis media tidak hanya untuk host. Klien dapat memainkan peran dalam jenis media apa yang dikembalikan oleh tuan rumah dengan mengambil bagian dalam negosiasi tipe konten.

Sumber daya yang diidentifikasi oleh satu URL dapat memiliki beberapa representasi. Ambil, misalnya, resep brokoli yang kami sebutkan sebelumnya. Resep tunggal mungkin memiliki representasi dalam bahasa yang berbeda (Inggris, Prancis, dan Jerman). Resepnya bahkan bisa memiliki representasi dalam berbagai format (HTML, PDF, dan teks biasa). Itu semua sumber daya yang sama dan resep yang sama, tetapi representasi yang berbeda.

Pertanyaan yang jelas adalah: Representasi apa yang harus dipilih oleh server? Jawabannya ada pada mekanisme negosiasi konten yang dijelaskan oleh spesifikasi HTTP. Ketika klien membuat permintaan HTTP ke URL, klien dapat menentukan jenis media yang akan diterima. Jenis media tidak hanya untuk host untuk menandai sumber daya keluar, tetapi juga bagi klien untuk menentukan jenis media yang ingin mereka konsumsi.

Klien menentukan apa yang akan diterima dalam pesan permintaan keluar. Sekali lagi, kita akan melihat detail dari pesan ini di sesi berikutnya, tetapi bayangkan permintaan untuk http://food.com/ mengatakan akan menerima representasi dalam bahasa Jerman. Terserah server untuk mencoba memenuhi permintaan. Tuan rumah mungkin mengirim sumber tekstual yang masih dalam bahasa Inggris, yang mungkin akan mengecewakan pengguna yang berbahasa Jerman, tetapi inilah mengapa kami menyebutnya negosiasi konten dan bukan ultimatum konten.

Browser web adalah perangkat lunak canggih yang dapat menangani berbagai jenis representasi sumber daya. Negosiasi konten adalah sesuatu yang mungkin tidak pernah diperhatikan oleh pengguna, tetapi untuk pengembang perangkat lunak (terutama pengembang layanan web), negosiasi konten adalah bagian dari apa yang membuat HTTP hebat. Sepotong kode yang ditulis dalam JavaScript dapat membuat permintaan ke server dan meminta representasi JSON. Sepotong kode yang ditulis dalam C++ dapat membuat permintaan ke server dan meminta representasi XML. Dalam kedua kasus, jika host dapat memenuhi permintaan, informasi akan sampai pada klien dalam format yang ideal untuk mengurai dan mengkonsumsinya.


Di mana kita?

Pada titik ini kita telah sampai sejauh yang kita bisa pergi tanpa masuk ke rincian seluk-beluk dari apa yang tampak seperti pesan HTTP. Kami telah belajar tentang URL, encoding URL, dan jenis konten. Saatnya untuk melihat seperti apa spesifikasi jenis konten ini saat mereka melakukan perjalanan melintasi kabel.

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.