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

HTTP: Protokol Yang Setiap Web Developer Wajib Tau - Bagian 1

by
Difficulty:IntermediateLength:LongLanguages:

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

HTTP merupakan singkatan dari Hypertext Transfer Protocol. Ini adalah stateless, protokol layer aplikasi untuk berkomunikasi antara sistem terdistribusi, dan merupakan dasar dari web modern. Sebagai pengembang web, kita semua harus memiliki pemahaman yang kuat tentang protokol ini.

Mari kita tinjau protokol yang kuat ini melalui lensa pengembang web. Kita akan mengatasi topiknya dalam dua bagian. Dalam entri pertama ini, kita akan membahas dasar-dasar dan menguraikan berbagai header request dan response. Pada artikel tindak lanjut, kita akan meninjau potongan khusus HTTP - yaitu caching, penanganan koneksi dan otentikasi.

Meskipun saya akan menyebutkan beberapa detail terkait header, sebaiknya kamu berkonsultasi dengan RFC (RFC 2616) untuk liputan yang mendalam. Saya akan menunjuk ke bagian-bagian yang spesifik dari RFC di sepanjang artikel.


Dasar-dasar HTTP

HTTP memungkinkan komunikasi antara berbagai host dan klien, dan mendukung campuran konfigurasi jaringan.

Untuk membuat ini mungkin, ia menganggap sangat sedikit terkait suatu sistem tertentu, dan tidak menjaga keadaan antara pertukaran pesan yang berbeda.

Ini menjadikan HTTP sebagai protokol stateless. Komunikasi biasanya terjadi melalui TCP/IP, tetapi transportasi yang dapat diandalkan juga dapat digunakan. Port default untuk TCP/IP adalah 80, tetapi port lain juga dapat digunakan.

Header khusus juga dapat dibuat dan dikirim oleh klien.

Komunikasi antara host dan klien terjadi, melalui sepasang request/response. Klien memulai pesan request HTTP, yang dilayani melalui pesan response HTTP sebagai balasannya. Kita akan melihat pada sepasang pesan fundamental ini di bagian selanjutnya.

Versi protokol saat ini adalah HTTP/1.1, yang menambahkan beberapa fitur tambahan ke versi 1.0 sebelumnya. Yang paling penting dari ini, menurut saya, termasuk persistent connectionschunked transfer-coding dan fine-grained caching headers. Kami akan secara singkat menyentuh fitur-fitur ini di artikel ini; cakupan mendalam akan disediakan di bagian kedua.

URLs

Inti dari komunikasi web adalah pesan request, yang dikirim melalui Uniform Resource Locators (URLs). Saya yakin kamu sudah terbiasa dengan URL, tetapi demi melengkapinya, saya akan menyertakannya di sini. URL memiliki struktur sederhana yang terdiri dari komponen-komponen berikut:

Protokol ini biasanya adalah http, tetapi juga bisa dengan https untuk komunikasi yang aman. Port default adalah 80, tetapi yang satu dapat diatur secara eksplisit, seperti yang diilustrasikan pada gambar di atas. Jalur sumber dayanya adalah local path ke sumber daya di server.

Verbs

Ada juga web debugging proxy, seperti Fiddler pada Windows dan Charles Proxy untuk OSX.

URL mengungkapkan identitas host tertentu yang ingin kita komunikasikan, tetapi tindakan yang harus dilakukan pada host ditentukan melalui HTTP verbs. Tentu saja, ada beberapa tindakan yang ingin dilakukan oleh klien. HTTP telah dirumuskan pada beberapa yang menangkap hal-hal penting yang berlaku secara universal untuk semua jenis aplikasi.

Verbs request ini adalah:

  • GET: mengambil sumber daya yang ada. URL berisi semua informasi yang diperlukan oleh server untuk mencari dan mengembalikan sumber daya.
  • POST: membuat sumber daya baru. Request POST biasanya membawa muatan yang menentukan data untuk sumber daya yang baru.
  • PUT: memperbarui sumber daya yang ada. Muatannya mungkin berisi data yang diperbarui untuk sumber daya.
  • Hapus: menghapus sumber yang ada.

Empat verbs di atas adalah yang paling populer, dan sebagian besar tool dan framework secara eksplisit mengekspos request verbs ini. PUT dan DELETE terkadang dianggap sebagai versi khusus dari verb POST, dan mereka dapat dikemas sebagai request POST dengan muatan yang berisi tindakan yang tepat: create, update atau delete.

Ada beberapa verb yang kurang digunakan, yang itu juga didukung oleh HTTP:

  • HEAD: ini mirip dengan GET, tetapi tanpa isi pesan. Ini digunakan untuk mengambil header server untuk sumber daya tertentu, umumnya untuk memeriksa apakah sumber daya telah berubah, melalui stempel waktu.
  • TRACE: digunakan untuk mengambil lompatan yang diminta oleh suatu request yang dibutuhkan untuk pulang-pergi dari server. Setiap proxy atau gerbang perantara akan menyuntikkan IP atau nama DNS-nya ke dalam field header Via. Ini dapat digunakan untuk tujuan diagnostik.
  • OPTIONS: digunakan untuk mengambil kapabilitas server. Di sisi klien, ini dapat digunakan untuk memodifikasi request berdasarkan apa yang dapat didukung oleh server.

Kode Status

Dengan URL dan verb, klien dapat memulai request ke server. Sebagai kembaliannya, server merespon dengan kode status dan muatan pesan. Kode status tersebut penting dan memberi tahu klien cara menafsirkan response server. Spesifikasi HTTP menentukan rentang angka tertentu untuk jenis respons tertentu:

1xx: Pesan Informasi

Semua klien HTTP/1.1 diminta untuk menerima header Transfer-Encoding.

Class kode ini diperkenalkan di HTTP/1.1 dan ini sekedar sementara. Server dapat mengirim pesan Expect: 100-continue, memberi tahu klien untuk terus mengirim sisa request, atau diabaikan jika sudah dikirim. Klien HTTP/1.0 seharusnya mengabaikan header ini.

2xx: Berhasil

Ini memberitahu klien bahwa request itu berhasil diproses. Kode yang paling umum adalah 200 OK. Untuk request GET, server mengirim sumber daya di isi pesan. Ada kode lain yang jarang digunakan:

  • 202 Diterima: request yang diterima tetapi mungkin tidak termasuk sumber daya di response. Ini berguna untuk pemrosesan async di sisi server. Server dapat memilih untuk mengirim informasi untuk pemantauan.
  • 204 Tanpa Isi: tidak ada isi pesan dalam response-nya.
  • 205 Atur Ulang Konten: menunjukkan kepada klien untuk mengatur ulang tampilan dokumennya.
  • 206 Konten Parsial: menunjukkan bahwa response hanya berisi sebagian konten. Header tambahan menunjukkan kisaran yang tepat dan informasi kedaluwarsa konten.

3xx: Pengalihan

404 menunjukkan bahwa sumber daya tidak valid dan tidak ada di server.

IHal ni mengharuskan klien untuk mengambil tindakan tambahan. Kasus penggunaan yang paling umum adalah melompat ke URL yang berbeda untuk mengambil sumber daya.

  • 301 Pindah Permanen: sumber daya yang sekarang berada di URL yang baru.
  • 303 Lihat Lainnya: sumber daya untuk sementara berada di URL baru. Header response Location berisi URL sementara.
  • 304 Tidak Dimodifikasi: server telah menetapkan bahwa sumber daya tidak berubah dan klien harus menggunakan salinan cache-nya. Ini bergantung pada fakta bahwa klien mengirim informasi ETag (Enttity Tag) yang merupakan hash konten. Server membandingkan ini dengan ETag yang dihitung untuk memeriksa modifikasi.

4xx: Kesalahan Klien

Kode-kode ini digunakan ketika server berpikir bahwa klien salah, baik dengan me-request sumber daya yang tidak valid atau membuat request yang buruk. Kode yang paling populer di kelas ini adalah 404 Not Found, yang saya rasa semua orang akan mengidentifikasikannya. 404 menunjukkan bahwa sumber dayanya tidak valid dan tidak ada di server. Kode-kode lain di kelas ini termasuk:

  • 400 Request Yang Buruk: request tersebut salah format.
  • 401 Tidak Sah: request membutuhkan otentikasi. Klien dapat mengulangi request dengan header Authorization. Jika klien sudah termasuk header otorisasi, maka kepercayaan yang salah.
  • 403 Terlarang: server telah menolak akses ke sumber daya.
  • 405 Metode Tidak Diizinkan: HTTP verb tidak valid yang digunakan dalam baris request, atau server tidak mendukung kata kerja itu.
  • 409 Konflik: server tidak dapat menyelesaikan request karena klien mencoba mengubah sumber daya yang lebih baru daripada stempel waktu klien. Konflik timbul terutama untuk request PUT selama pengeditan kolaboratif pada sumber daya.

5xx: Kesalahan Server

Class kode ini digunakan untuk menunjukkan kegagalan server saat memproses request. Kode kesalahan yang paling sering digunakan adalah 500 Internal Server Error. Yang lain di class ini adalah:

  • 501 Tidak Diimplementasikan: server belum mendukung fungsionalitas yang diminta.
  • 503 Layanan Tidak Tersedia: ini dapat terjadi jika sistem internal pada server gagal atau server kelebihan beban. Biasanya, server tidak akan merespon dan waktu request-nya akan habis.

Format Pesan Request dan Response

Sejauh ini, kami telah melihat bahwa URL, verb dan  status code merupakan bagian mendasar dari sepasang request/reponse HTTP.

Mari sekarang lihat konten pesan-pesan ini. Spesifikasi HTTP menyatakan bahwa pesan request atau response memiliki struktur umum berikut:

Hal ini wajib untuk menempatkan baris baru antara header dan isi pesan. Pesan dapat berisi satu atau beberapa header, yang secara garis besar diklasifikasikan menjadi:

Isi pesan mungkin berisi data entitas lengkap, atau mungkin sedikit demi sedikit jika encoding chunked (Transfer-Encoding: chunked) digunakan. Semua klien HTTP/1.1 diminta untuk menerima header Transfer-Encoding.

General Headers

Ada beberapa header (general header) yang dibagikan oleh kedua pesan request dan response:

Kita telah melihat beberapa header ini, khususnya Via dan Transfer-Encoding. Kita akan membahas Cache-Control dan Connection di bagian kedua.

Kode status termasuk hal penting dan memberi tahu klien cara menafsirkan response server.

  • Header Via digunakan dalam pesan TRACE dan diperbarui oleh semua proxy dan gerbang yang berselang sebentar.
  • Pragma dianggap sebagai suatu haeder khusus dan dapat digunakan untuk menyertakan header khusus implementasi. Pragma-directive yang paling sering digunakan adalah Pragma: no-cache, yang sebenarnya adalah Cache-Control: no-cache di bawah HTTP/1.1. Hal ini akan dibahas di bagian ke 2 artikel.
  • Field header Date digunakan untuk memberi stempel waktu pada pesan request/response
  • Upgrade digunakan untuk mengganti protokol dan memungkinkan transisi yang mulus ke protokol yang lebih baru.
  • Transfer-Encoding umumnya digunakan untuk memecah response menjadi bagian-bagian yang lebih kecil dengan nilai Transfer-Encoding: chunked. Ini adalah header baru di HTTP/1.1 dan memungkinkan pengaliran respons ke klien, bukan hanya satu muatan besar.

Entity header

Pesan Request dan Response juga dapat menyertakan header entitas untuk memberikan informasi meta mengenai konten (alias Isi Pesan atau Entitas). Header ini meliputi:

Semua prefix header Content- menyediakan informasi tentang struktur, encoding dan ukuran isi pesan. Beberapa header ini harus ada jika entitas adalah bagian dari pesan.

Header Expires menunjukkan stempel waktu ketika entitas berakhir. Yang menarik, entitas "never expires" dikirim dengan stempel waktu satu tahun ke depan. Header Last-Modified mengindikasikan stempel waktu modifikasi terakhir untuk entitas.

Header khusus juga dapat dibuat dan dikirim oleh klien; mereka akan diperlakukan sebagai header entitas oleh protokol HTTP.

Ini benar-benar sebuah mekanisme ekstensi, dan beberapa implementasi client-server dapat memilih untuk berkomunikasi secara khusus melalui header ekstensi ini. Meskipun HTTP mendukung header khusus, apa yang sebenarnya dicari adalah header request dan response, yang akan kita bahas selanjutnya.

Format Request

Pesan request memiliki struktur generik yang sama seperti di atas, kecuali untuk baris request yang terlihat seperti:

SP adalah ruang pemisah antar token. HTTP-Version ditetapkan sebagai "HTTP / 1.1" dan kemudian diikuti oleh garis baru. Dengan demikian, pesan request yang khas mungkin terlihat seperti:

Perhatikan baris request diikuti dengan banyak header request. Header Host wajib untuk klien HTTP/1.1. Request GET tidak memiliki isi pesan, tetapi request POST dapat berisi data post di bagian isi nya.

Request header bertindak sebagai pengubah pesan request. Daftar lengkap header request yang diketahui tidak terlalu panjang, dan disediakan di bawah ini. Header yang tidak dikenal diperlakukan sebagai field header entitas.

Header dengan prefix Accept yang diterima menunjukkan jenis media yang dapat diterima, bahasa dan rangkaian karakter pada klien. FromHostReferer dab User-Agent mengidentifikasi detail tentang klien yang memulai request. Header dengan prefix If- digunakan untuk membuat request yang lebih bersyarat, dan server hanya mengembalikan sumber daya jika kondisinya cocok. Jika tidak, ia mengembalikan 304 Not Modified. Kondisi ini dapat didasarkan pada stempel waktu atau ETag (hash entitas).

Format Response

Format response mirip dengan pesan request, kecuali untuk baris status dan header. Baris status memiliki struktur berikut:

  • Versi HTTP dikirim sebagai HTTP/1.1
  • Status-Code adalah salah satu dari banyak status yang dibahas sebelumnya.
  • Reason-Phrase adalah versi kode status yang mudah dibaca oleh manusia.

Baris status tipikal untuk respons yang sukses mungkin terlihat seperti ini:

Header response juga cukup terbatas, dan rangkaian lengkap diberikan di bawah ini:

  • Age adalah waktu dalam detik sejak pesan dibuat di server.
  • ETag adalah hash MD5 dari entitas dan digunakan untuk mengecek modifikasi.
  • Location digunakan saat mengirim pengalihan dan berisi URL baru.
  • Server mengidentifikasi server yang menghasilkan pesan.

Sudah banyak teori sampai titik ini, jadi saya tidak akan menyalahkanmu untuk mata mengantuk. Pada bagian selanjutnya, kita akan menjadi lebih praktis dan melakukan survei terhadap tool, framework dan library.


Beberapa Tool untuk Melihat Trafik HTTP

Ada sejumlah tool yang tersedia untuk memonitor komunikasi HTTP. Di sini, kami membuat daftar beberapa tool yang lebih populer.

Tidak diragukan lagi, Chrome/Webkit inspector termasuk yang terpopuler di antara pengembang web:

Ada juga proxy debugging web, seperti Fiddler pada Windows dan Charles Proxy untuk OSX. Rekan saya, Rey Bango menulis artikel yang sangat bagus tentang topik ini.

Fiddler
Charles Proxy

Untuk baris perintah, kita memiliki utilitas seperti curl, tcpdump dan tshark untuk memonitor trafik HTTP.


Menggunakan HTTP di Framework dan Library Web

Sekarang setelah kita melihat pesan request/response, inilah saatnya kita mempelajari bagaimana library dan framework memaparkannya dalam bentuk API. Kita akan menggunakan ExpressJS untuk Node, Ruby on Rails, dan jQuery Ajax sebagai contoh kita.

ExpressJS

Jika kamu membangun server web di NodeJS, kemungkinan besar kamu telah mempertimbangkan ExpressJS. ExpressJS awalnya terinspirasi oleh framework web Ruby, yang disebut Sinatra. Seperti yang diharapkan, API juga sama-sama dipengaruhi.

Karena kita berurusan dengan framework di sisi server, ada dua tugas utama ketika berhadapan dengan pesan HTTP:

  • Membaca fragmen URL dan header request.
  • Menulis response header dan body

Memahami HTTP sangat penting untuk memiliki antarmuka yang bersih, sederhana dan RESTful antara dua endpoint.

ExpressJS menyediakan API sederhana untuk melakukan hal tersebut. Kita tidak akan membahas detail mengenai API. Sebaliknya, kita akan memberikan tautan ke dokumentasi terperinci tentang panduan ExpressJS. Metode di API cukup jelas dalam banyak kasus. Contoh dari request terkait API ada di bawah ini:

Dalam perjalanan ke klien, ExpressJS menyediakan response API berikut:

  • res.status: mengatur kode status yang eksplisit.
  • res.set: mengatur header respons yang spesifik.
  • res.send: mengrim HTML, JSON atau octet-stream.
  • res.sendFile: mentransfer file ke klien.
  • res.render: me-render template tampilan express.
  • res.redirect: mengalihkan ke route lain. Express secara otomatis menambahkan kode pengalihan default 302.

Ruby on Rails

Pesan request dan response sebagian besar sama, kecuali untuk baris pertama dan header pesan.

Di Rails, modul ActionController dan ActionDispatch menyediakan API untuk menangani pesan request dan response.

ActionController menyediakan API tingkat tinggi untuk membaca request URL, menampilkan output dan mengarahkan ulang ke end-point yang berbeda. Suatu end-point (alias route) ditangani sebagai metode tindakan. Sebagian besar informasi konteks yang diperlukan di dalam metode aksi disediakan melalui request, respons dan objek params.

  • params: memberi akses ke parameter URL dan data POST.
  • request: berisi informasi tentang klien, header, dan URL.
  • response: digunakan untuk menyetel header dan status code.
  • render: me-render tampilan dengan mengembangkan template.
  • redirect_to: mengarahkan ulang ke metode aksi atau URL yang berbeda.

ActionDispatch menyediakan akses modular ke request/response, melalui class ActionDispatch::Request dan ActionDispatch::Response. Ini memperlihatkan satu set metode query untuk memeriksa jenis request (get?()post?()head?()local?()). Header request dapat langsung diakses melalui metode request.headers() .

Di sisi respons, ia menyediakan metode untuk mengatur cookies(), location=() dan status=(). Jika kamu merasa ingin bertualang, kamu juga dapat mengatur body=() dan mem-bypass sistem rendering Rails.

jQuery Ajax

Karena jQuery adalah pada dasarnya suatu library di sisi-klien, Ajax API-nya menyediakan kebalikan dari framework di  sisi server. Dengan kata lain, ini memungkinkanmu untuk membaca pesan respons dan memodifikasi pesan request. jQuery mengekspos API sederhana melalui jQuery.ajax(settings):

Dengan mengirimkan objek settings dengan callback beforeSend, kita dapat memodifikasi header request. Callback menerima objek jqXHR (jQuery XMLHttpRequest) yang mengekspos metode, yang disebut setRequestHeader() untuk mengatur header.

  • Objek jqXHR juga dapat digunakan untuk membaca header response dengan jqXHR.getResponseHeader().
  • Jika kamu ingin mengambil tindakan tertentu untuk berbagai kode status, kamu dapat menggunakan callback statusCode:

Ringkasan

Jadi, berikutrangkuman tur singkat kita dari protokol HTTP.

Kita meninjau struktur URL, verb, dan status code: tiga pilar dari komunikasi HTTP.

Pesan request dan response sebagian besar sama, kecuali untuk baris pertama dan header pesan. Akhirnya, kita meninjau bagaimana kamu dapat memodifikasi header request dan response di framework dan library web.

Memahami HTTP sangat penting untuk memiliki antarmuka yang bersih, sederhana, dan RESTful antara dua endpoint. Pada skala yang lebih besar, itu juga membantu ketika merancang infrastruktur jaringanmu dan memberikan pengalaman hebat kepada pengguna akhirmu.

Di bagian kedua, kita akan meninjau penanganan koneksi, otentikasi dan caching! Sampai jumpa.


Referensi

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.