Web Service Adalah: Cara Kerja, Jenis & Bedanya dari API

Setiap aplikasi yang Anda pakai sehari-hari hampir tidak pernah bekerja sendirian. Aplikasi ojek online menampilkan peta yang bukan miliknya. Toko online menampilkan status pengiriman yang datanya ada di sistem perusahaan ekspedisi. Aplikasi cuaca di ponsel Anda tidak punya satu pun stasiun pengamatan.

Semua contoh itu memunculkan pertanyaan yang sama. Bagaimana caranya dua aplikasi yang ditulis tim berbeda, dengan bahasa pemrograman berbeda, bisa saling bertukar data dengan rapi? Apalagi keduanya berjalan di server yang terpisah. Jawabannya adalah web service.

Apa Itu Web Service?

Web service adalah sistem perangkat lunak yang memungkinkan dua aplikasi bertukar data lewat jaringan komputer. Perbedaan bahasa pemrograman maupun sistem operasi di kedua sisi tidak menjadi penghalang.

W3C (World Wide Web Consortium, lembaga yang menetapkan standar teknologi web) merumuskannya secara lebih ketat dalam dokumen Web Services Architecture tahun 2004. Menurut rumusan tersebut, web service adalah sistem perangkat lunak yang dirancang untuk mendukung interaksi antar-mesin melalui jaringan. Antarmukanya dijelaskan dalam format yang bisa diproses mesin.

Dari definisi tersebut, ada tiga syarat yang membuat sesuatu layak disebut web service:

1. Berjalan lewat jaringan: Komunikasinya menempuh jaringan komputer, umumnya internet. Ini syarat mutlak yang membedakannya dari komponen perangkat lunak biasa.
2. Komunikasi antar-mesin: Yang saling berbicara adalah program dengan program, bukan manusia dengan program. Karena itu jawabannya tidak berupa halaman berwarna, melainkan data mentah yang terstruktur.
3. Antarmuka yang bisa dibaca mesin: Ada kontrak yang menjelaskan layanan apa saja yang tersedia, data apa yang harus dikirim, dan jawaban seperti apa yang akan diterima.

Jangan Tertukar dengan Web Server dan Aplikasi Web

Tiga istilah ini bunyinya mirip, tetapi merujuk pada hal yang sangat berbeda. Kekeliruan memahaminya sering menghambat pembahasan selanjutnya.

Web server adalah perangkat lunak yang melayani permintaan HTTP dan mengirimkan berkas ke peminta, misalnya Nginx atau Apache. Ia adalah pelayan yang mengantarkan.

Aplikasi web adalah program yang dipakai manusia lewat browser, seperti Gmail atau dashboard toko online. Keluarannya adalah tampilan yang enak dilihat mata.

Web service berada di lapisan yang berbeda lagi. Ia berjalan di atas web server, tetapi pemakainya bukan manusia melainkan aplikasi lain. Keluarannya bukan tampilan, melainkan data siap olah.

Cara Kerja Web Service: Perjalanan Satu Permintaan

Web service bekerja dengan model client-server (klien-peladen). Satu pihak berperan sebagai peminta, satu pihak lain berperan sebagai penyedia. Keduanya bertukar pesan dalam siklus permintaan dan jawaban yang selalu berulang dengan pola sama.

Diagram alur kerja web service, dari permintaan aplikasi klien sampai data dikirim balik dan ditampilkan.

Mari kita telusuri satu per satu dengan contoh aplikasi kurs mata uang.

Pertama, aplikasi klien menyusun permintaan. Aplikasi kurs ingin tahu nilai tukar dolar terhadap rupiah hari ini. Ia menyiapkan permintaan berisi keterangan mata uang asal dan mata uang tujuan.

Kedua, permintaan dikirim ke alamat tujuan. Alamat ini disebut endpoint, bentuknya berupa URL seperti alamat website biasa. Bedanya, endpoint tidak dimaksudkan untuk dibuka manusia lewat browser.

Ketiga, server memeriksa identitas peminta. Hampir semua web service serius menuntut bukti bahwa peminta berhak mengakses data tersebut. Buktinya bisa berupa kunci akses (API key), token, atau pasangan identitas dan kata sandi.

Keempat, server mengambil dan menyiapkan data. Server menghubungi basis datanya, mengambil angka kurs terbaru, lalu membungkusnya dalam format yang disepakati.

Kelima, jawaban dikirim balik dan diolah klien. Aplikasi kurs menerima angka mentah tersebut, lalu menampilkannya dengan tata letak dan warna sesuai desainnya sendiri.

Perhatikan langkah keempat. Data yang dikirim balik berbentuk teks terstruktur seperti JSON atau XML, bukan HTML. Alasannya sederhana: HTML mengandung instruksi tampilan yang hanya berguna bagi mata manusia. Aplikasi penerima justru terganggu oleh instruksi tersebut karena yang ia butuhkan hanya nilai datanya.

Web Service dan API: Hubungan Induk dan Anak

Di sinilah banyak orang tersandung. Dua istilah ini sering dipakai bergantian seolah artinya sama persis. Kenyataannya tidak demikian, dan memahami perbedaannya membuat banyak hal lain menjadi jelas.

API (Application Programming Interface) adalah istilah yang jauh lebih luas. API adalah setiap perjanjian yang memungkinkan satu potong perangkat lunak memanggil kemampuan perangkat lunak lain. Perjanjian itu tidak harus melibatkan jaringan sama sekali.

Web service adalah himpunan bagian dari API — tepatnya, API yang berkomunikasi lewat jaringan. Kalimat yang paling akurat berbunyi begini: setiap web service adalah API, tetapi tidak setiap API adalah web service.

Contoh tandingannya mudah ditemukan. Ketika Anda menulis program Python dan memanggil fungsi dari pustaka pengolah gambar yang terpasang di komputer Anda, Anda sedang memakai API. Tidak ada satu pun paket data yang keluar dari komputer tersebut. Karena tidak melibatkan jaringan, pustaka itu bukan web service.

Diagram lingkaran bersarang: web service berada di dalam lingkaran API sebagai himpunan bagiannya.

Dua Gaya Web Service: SOAP dan REST

Sepanjang sejarahnya, web service dibangun dengan dua pendekatan besar. Keduanya sama-sama mengirim data lewat jaringan, tetapi cara membungkus dan mengatur pesannya berbeda jauh.

Membedah Amplop SOAP

SOAP (Simple Object Access Protocol) adalah pendekatan yang lebih tua dan jauh lebih formal. Setiap pesan SOAP dibungkus dalam struktur XML yang aturannya sudah dibakukan W3C. Struktur ini biasa disebut amplop, dan susunannya berlapis:

1. Envelope: Lapisan terluar yang membungkus seluruh pesan. Elemen ini wajib ada dan menandai bahwa dokumen tersebut adalah pesan SOAP.
2. Header: Lapisan opsional untuk keterangan tambahan di luar isi utama, misalnya data autentikasi atau penanda transaksi.
3. Body: Lapisan wajib yang memuat isi sesungguhnya, yaitu data yang dikirim atau permintaan yang diajukan.
4. Fault: Elemen khusus di dalam Body yang muncul hanya ketika terjadi kesalahan. Isinya mencakup kode kesalahan, alasan, penanda titik yang bermasalah, dan detail teknis.

Supaya tidak berhenti di teori, berikut wujud nyata satu pesan SOAP yang menanyakan kurs dolar terhadap rupiah:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <auth:Token xmlns:auth="https://contoh.id/auth">abc123</auth:Token>
  </soap:Header>
  <soap:Body>
    <m:CekKurs xmlns:m="https://contoh.id/kurs">
      <m:Dari>USD</m:Dari>
      <m:Ke>IDR</m:Ke>
    </m:CekKurs>
  </soap:Body>
</soap:Envelope>

Perhatikan betapa banyak penanda yang dibutuhkan hanya untuk menyampaikan dua nilai, yaitu USD dan IDR. Alamat http://www.w3.org/2003/05/soap-envelope pada baris kedua adalah penanda resmi versi SOAP 1.2 yang wajib dicantumkan. Seandainya permintaan ini gagal, server akan membalas dengan struktur serupa yang di dalam Body-nya berisi elemen Fault.

Pasangan wajib SOAP adalah WSDL (Web Services Description Language), sebuah berkas XML yang berperan sebagai kontrak. Berkas ini mendaftar seluruh operasi yang tersedia beserta tipe data setiap parameternya. Karena kontraknya kaku dan bisa dibaca mesin, banyak perkakas pengembangan sanggup membangkitkan kode pemanggil secara otomatis dari WSDL.

Diagram struktur amplop SOAP: Envelope membungkus Header dan Body, dengan elemen Fault di dalam Body.

Ada satu sifat SOAP yang sering luput diperhatikan: SOAP tidak terikat pada HTTP. Spesifikasi W3C secara tegas mengizinkan pesan SOAP dikirim lewat protokol lain, termasuk aliran TCP langsung maupun SMTP. Fleksibilitas inilah yang membuatnya bertahan di lingkungan perusahaan besar dengan jalur komunikasi yang tidak biasa.

REST dan Pergeseran ke JSON

REST (Representational State Transfer) mengambil arah yang berlawanan. Alih-alih menciptakan lapisan amplop sendiri, REST memanfaatkan mekanisme HTTP yang sudah ada.

Setiap data diperlakukan sebagai sumber daya yang punya alamat URL sendiri. Perbuatan terhadap data ditentukan oleh metode HTTP: GET untuk membaca, POST untuk menambah, PUT untuk memperbarui, dan DELETE untuk menghapus. Tidak ada kontrak XML yang harus disusun lebih dulu.

Formatnya pun bergeser. REST umumnya memakai JSON yang jauh lebih ringkas dibanding XML. Permintaan kurs yang tadi memenuhi belasan baris XML cukup ditulis sebagai satu alamat:

GET /v1/kurs?dari=USD&ke=IDR

Jawabannya pun sependek ini:

{
  "dari": "USD",
  "ke": "IDR",
  "nilai": 16250,
  "diperbarui": "2026-07-19T08:00:00Z"
}

Tidak ada amplop, tidak ada penanda namespace, tidak ada berkas kontrak yang harus dibaca lebih dulu. Informasi yang sampai ke aplikasi Anda persis sama dengan versi SOAP tadi.

Konsekuensinya terasa langsung. Pesan yang lebih ringkas berarti data yang dikirim lebih sedikit, waktu tunggu lebih pendek, dan beban pengolahan di kedua sisi lebih ringan. Untuk aplikasi ponsel yang koneksinya naik turun, keunggulan ini sangat berarti.

Contoh Web Service yang Anda Pakai Setiap Hari

Konsep ini terasa abstrak sampai Anda menyadari betapa seringnya web service bekerja di balik layar.

Empat contoh web service sehari-hari: ikon peta, cuaca, kartu pembayaran, dan tiket.

Peta di aplikasi transportasi online. Aplikasi ojek online tidak memetakan jalanan Indonesia sendiri. Ia mengirim koordinat Anda ke web service penyedia peta, lalu menerima balasan berupa data jalur dan perkiraan waktu tempuh.

Ramalan cuaca di layar ponsel. Aplikasi cuaca mengirim nama kota ke web service milik badan meteorologi atau penyedia data cuaca, lalu menerima angka suhu, kelembapan, dan peluang hujan.

Pembayaran di toko online. Saat Anda menekan tombol bayar, toko online mengirim jumlah tagihan ke web service penyedia pembayaran. Nomor kartu Anda tidak pernah disimpan toko tersebut, karena yang menanganinya adalah layanan pembayaran.

Masuk dengan akun Google. Tombol "Masuk dengan Google" bekerja lewat web service. Aplikasi mengirim permintaan verifikasi ke server Google, lalu menerima jawaban berisi identitas dasar Anda tanpa pernah menyentuh kata sandi.

Cek ketersediaan kursi tiket. Situs penjualan tiket menanyakan sisa kursi ke web service maskapai atau operator kereta secara langsung. Karena itulah angka yang muncul selalu sesuai dengan kondisi terkini.

Kenapa Istilah Ini Masih Sering Terdengar di Indonesia

Ada alasan historis mengapa "web service" terasa berbau lama sementara "API" terdengar lebih modern. Definisi resmi W3C tahun 2004 menyebut WSDL secara eksplisit sebagai format antarmukanya. Selama bertahun-tahun sesudahnya, menyebut web service praktis berarti menyebut SOAP beserta seluruh perangkatnya.

Arah industri kemudian berubah tajam. Sekitar 93% organisasi kini menjadikan REST sebagai standar, dan sekitar 85% API baru dibangun dengan gaya REST. Sementara itu, sekitar 15% API di sektor perbankan, kesehatan, dan sistem ERP masih berbasis SOAP.

Angka terakhir itulah yang menjelaskan kenapa istilah ini belum pensiun di Indonesia. Integrasi sistem rumah sakit dengan BPJS Kesehatan, misalnya, secara resmi dinamai "webservice" dalam dokumentasinya, lengkap dengan mekanisme Consumer ID dan Consumer Secret pada header HTTP. Pemanfaatan data kependudukan Dukcapil oleh instansi lain juga berjalan lewat web service.

Menariknya, layanan BPJS Kesehatan sendiri sudah bergerak ke REST — terlihat dari penamaan versi terbarunya. Namun sebutan "webservice" tetap dipertahankan. Bagi Anda yang akan magang atau bekerja di rumah sakit, bank, maupun instansi pemerintah, istilah ini akan Anda temui dalam dokumen teknis sehari-hari.

Kelemahan dan Hal yang Perlu Dipertimbangkan

Web service menyelesaikan banyak persoalan, tetapi ia juga membawa konsekuensi yang perlu Anda pahami sejak awal.

1. Bergantung penuh pada jaringan: Ketika koneksi terputus, seluruh fitur yang mengandalkan web service ikut berhenti. Aplikasi Anda perlu menyiapkan perilaku cadangan saat panggilan gagal.
2. Menambah waktu tunggu: Setiap panggilan menempuh perjalanan bolak-balik lewat jaringan. Satu halaman yang memanggil lima web service secara berurutan akan terasa lambat, sekalipun tiap panggilan hanya butuh 200 milidetik.
3. Memperluas titik rawan keamanan: Setiap endpoint yang terbuka ke internet adalah pintu tambahan yang bisa diketuk pihak tidak berkepentingan. Autentikasi, pembatasan jumlah panggilan, dan enkripsi bukan pelengkap melainkan keharusan.
4. Menyerahkan kendali ke pihak lain: Ketika penyedia mengubah format jawaban, menaikkan harga, atau menghentikan layanan, aplikasi Anda terkena dampaknya secara langsung.
5. Menimbulkan biaya per pemakaian: Banyak web service komersial menagih berdasarkan jumlah panggilan. Fitur yang memanggil layanan berbayar di setiap pemuatan halaman bisa menghasilkan tagihan yang mengejutkan.
6. Membutuhkan perawatan versi: Penyedia yang baik menyediakan beberapa versi sekaligus, tetapi versi lama tetap akan dihentikan pada waktunya. Anda perlu menyiapkan waktu untuk penyesuaian berkala.

Memilih Antara SOAP dan REST

Sebelum masuk ke rekomendasi, berikut ringkasan perbedaan keduanya dalam satu tampilan:

Untuk proyek baru, pilihannya cukup jelas. Pakai REST, kecuali ada alasan kuat yang memaksa sebaliknya. Adopsi REST yang mencapai 85% pada API baru berarti dokumentasi, pustaka pendukung, dan calon rekan kerja yang memahaminya jauh lebih melimpah.

SOAP masih masuk akal dalam tiga keadaan berikut:

1. Pihak lawan hanya menyediakan SOAP. Sistem inti perbankan, penyedia asuransi, dan sebagian sistem pemerintahan sering hanya membuka antarmuka SOAP. Dalam hal ini Anda tidak sedang memilih.
2. Transaksi menuntut jaminan ketat. SOAP memiliki standar bawaan untuk transaksi yang harus berhasil seluruhnya atau gagal seluruhnya. Untuk perpindahan dana antarbank, jaminan semacam ini penting.
3. Kontrak antarmuka harus kaku dan dapat diperiksa. Ketika dua organisasi terikat perjanjian formal, WSDL memberi acuan yang tidak bisa ditafsirkan berbeda oleh kedua pihak.

Di luar tiga keadaan tersebut, membangun web service SOAP baru pada tahun ini akan menyulitkan Anda sendiri.

Langkah Awal Membuat Web Service Sendiri

Membangun web service pertama Anda tidak serumit kelihatannya. Urutannya kira-kira seperti ini.

Langkah #1: Tentukan data yang dibuka. Putuskan data mana yang boleh diakses aplikasi lain dan data mana yang harus tetap tertutup. Batasan ini lebih mudah ditetapkan di awal daripada dicabut belakangan.

Langkah #2: Rancang endpoint dan format jawaban. Tetapkan alamat untuk setiap jenis data, misalnya /produk untuk daftar produk dan /produk/12 untuk satu produk tertentu. Tentukan pula susunan JSON yang akan dikembalikan.

Langkah #3: Pilih bahasa dan kerangka kerjanya. Hampir semua bahasa modern punya kerangka kerja yang cocok, misalnya Laravel untuk PHP, Express untuk Node.js, atau FastAPI untuk Python. Pilih yang paling Anda kuasai.

Langkah #4: Pasang autentikasi. Tambahkan pemeriksaan kunci akses atau token sebelum permintaan diproses. Endpoint tanpa penjaga akan ditemukan pemindai otomatis dalam hitungan hari.

Langkah #5: Tulis dokumentasi. Jelaskan setiap endpoint, parameter yang diterima, dan contoh jawaban. Web service tanpa dokumentasi praktis tidak bisa dipakai orang lain.

Langkah #6: Uji dengan perkakas pemanggil. Pakai aplikasi seperti Postman atau perintah curl untuk memanggil endpoint Anda dari luar, lalu periksa apakah jawabannya sesuai rancangan.

Selalu sertakan nomor versi pada alamat endpoint Anda, misalnya /v1/produk. Ketika suatu saat format jawaban perlu diubah, Anda bisa menerbitkan /v2/produk tanpa merusak aplikasi yang sudah memakai versi sebelumnya.

Pertanyaan yang Sering Muncul

Apakah web service sama dengan API?

Tidak sama, tetapi berkerabat dekat. Web service adalah salah satu bentuk API, yaitu bentuk yang berkomunikasi lewat jaringan. API mencakup lebih banyak hal, termasuk pemanggilan fungsi antar-komponen di dalam satu komputer yang tidak melibatkan jaringan sama sekali.

Apakah Amazon Web Services termasuk web service?

Bukan dalam arti yang dibahas di artikel ini. Amazon Web Services (AWS) adalah nama merek penyedia layanan komputasi awan, bukan sebuah konsep teknis. Kebetulan saja namanya memuat kata "web service". AWS memang menyediakan banyak web service di dalam produknya, tetapi keduanya adalah dua hal berbeda.

Apa saja jenis web service?

Berdasarkan cara pesannya disusun, ada dua jenis utama, yaitu SOAP yang memakai amplop XML baku dan REST yang memanfaatkan mekanisme HTTP dengan format JSON. Di luar keduanya ada pendekatan yang lebih baru seperti GraphQL dan gRPC, tetapi dua jenis utama tadi yang paling sering Anda temui.

Web service dan web server itu sama atau berbeda?

Berbeda. Web server adalah perangkat lunak yang melayani permintaan dan mengirimkan berkas, misalnya Nginx atau Apache. Web service adalah layanan yang berjalan di atas web server tersebut, dan pemakainya aplikasi lain, bukan manusia.

Bahasa pemrograman apa yang dipakai membuat web service?

Bahasa apa pun bisa dipakai, karena web service justru dirancang agar perbedaan bahasa tidak menjadi masalah. Yang umum di Indonesia adalah PHP dengan Laravel, JavaScript dengan Node.js, dan Python dengan Django atau FastAPI. Aplikasi pemanggilnya boleh ditulis dengan bahasa yang sama sekali berbeda.

Apakah web service selalu berbayar?

Tidak. Banyak web service terbuka gratis, misalnya layanan data cuaca publik dan data wilayah administrasi Indonesia. Layanan komersial umumnya memberi kuota gratis terbatas, lalu menagih setelah jumlah panggilan Anda melewati batas tersebut.

Kesimpulan

Web service adalah cara dua aplikasi berbeda saling bertukar data lewat jaringan, dengan pesan berformat terstruktur yang dapat dibaca mesin. Posisinya adalah himpunan bagian dari API — setiap web service pasti API, tetapi API yang bekerja tanpa jaringan bukanlah web service.

Untuk membangun layanan baru, REST dengan format JSON adalah pilihan yang paling masuk akal saat ini. SOAP tetap perlu Anda kenali karena masih menopang sistem di sektor perbankan, kesehatan, dan pemerintahan. Di Indonesia, kemungkinan besar di sanalah Anda pertama kali bertemu istilah ini secara langsung.

Semoga artikel ini membantu.