Apa itu perkhidmatan web?

Perkhidmatan web ialah antara muka yang membolehkan aplikasi bertukar data atau memanggil fungsi melalui rangkaian. Laman web direka terutamanya untuk dibaca dan digunakan oleh manusia, manakala perkhidmatan web mendedahkan kontrak yang ditujukan kepada klien perisian. Produk yang sama boleh menyediakan kedua-duanya. Banyak perkhidmatan menggunakan HTTP dan JSON, tetapi istilah ini turut merangkumi protokol dan format data lain.

Cara permintaan dan respons berfungsi

Klien menghantar permintaan ke titik akhir yang ditetapkan beserta kaedah, parameter dan, jika diperlukan, bukti kelayakan. Perkhidmatan mengesahkan permintaan, melaksanakan operasinya dan memulangkan respons. Bagi API HTTP, kod status membezakan hasil secara umum: respons yang berjaya, masalah di pihak klien seperti input tidak sah, atau kegagalan di pihak pelayan. Badan respons biasanya memberikan butiran lanjut dalam format yang didokumenkan.

Kontrak yang jelas menerangkan laluan, kaedah, medan, jenis, pengesahan, had kadar dan keadaan ralat. Kontrak ini membolehkan klien dibangunkan secara bebas. Pemversian penting kerana mengubah sesuatu medan atau tafsirannya boleh merosakkan aplikasi sedia ada walaupun alamat titik akhir kekal sama. Kekalkan keserasian ke belakang jika telah dijanjikan dan umumkan tempoh penamatan sokongan.

Gaya antara muka yang biasa

REST ialah gaya seni bina, bukan satu format data tunggal. API HTTP yang digambarkan sebagai RESTful lazimnya mewakili sumber dengan URL dan menggunakan kaedah seperti GET untuk membaca serta POST atau PUT untuk perubahan. GET tidak sepatutnya mencipta perubahan keadaan yang kekal; klien dan perantara mungkin mengulang atau menyimpannya dalam cache. SOAP menggunakan mesej XML berstruktur dan penerangan perkhidmatan formal dalam banyak sistem perusahaan.

GraphQL membolehkan klien meminta pilihan medan tertentu melalui skema, selalunya melalui HTTP. Ia boleh mengurangkan pemindahan data yang tidak perlu, tetapi menambah kerumitan dari segi kos pertanyaan, kebenaran dan cache. Webhook menterbalikkan corak tinjauan biasa: satu perkhidmatan memanggil titik akhir yang didaftarkan apabila sesuatu peristiwa berlaku. Webhook memerlukan pengesahan pengirim, pengendalian cubaan semula dan perlindungan terhadap penghantaran berganda. Tiada satu pun pendekatan ini yang terbaik dalam semua keadaan.

Keselamatan dan privasi

Gunakan HTTPS untuk melindungi data semasa dihantar dan sahkan sijil pelayan. Sahkan pemanggil dengan skim bukti kelayakan yang sesuai dan semak kebenaran bagi setiap operasi dan objek secara berasingan. Token yang sah hanya membuktikan apa yang dibenarkan oleh skopnya; ia tidak menjadikan sebarang input selamat. Sahkan saiz dan jenis permintaan, elakkan mendedahkan data peribadi dalam mesej ralat, dan tetapkan had untuk mencegah penyalahgunaan.

Rahsia tidak sepatutnya muncul dalam URL awam, kod sumber di pihak klien atau log. Tukar bukti kelayakan yang terdedah, hadkan skopnya dan gunakan bukti kelayakan berasingan untuk persekitaran pengeluaran dan ujian. Bagi API yang menerima URL panggilan balik, sahkan destinasinya untuk mengelakkan permintaan ke rangkaian dalaman. Dokumenkan data peribadi yang dipulangkan dan simpan hanya apa yang diperlukan.

Kebolehpercayaan dan prestasi

Rangkaian boleh gagal, jadi klien memerlukan had masa, cubaan semula yang terhad dan pengendalian kegagalan separa yang jelas. Ulang operasi baca apabila selamat; mengulang pembayaran atau perubahan lain memerlukan reka bentuk idempoten untuk mengelakkan pendua. Penomboran halaman mengehadkan set keputusan yang besar. Cache boleh mengurangkan beban bagi data awam yang stabil, manakala respons yang cepat berubah atau bersifat peribadi memerlukan dasar cache yang teliti.

Pengendali perlu mengukur kependaman, kadar ralat dan ketersediaan daripada laluan klien sebenar. Pelayan yang memulangkan HTTP 200 masih boleh memberikan data yang tidak lengkap atau tidak boleh digunakan, jadi pantau juga hasil perniagaan yang dijangka. Had kadar melindungi perkhidmatan tetapi perlu dimaklumkan dengan cara yang boleh dijangka. Sediakan halaman status atau saluran sokongan untuk insiden jika perkhidmatan itu penting kepada pengguna.

Memilih atau membina perkhidmatan

Mulakan dengan tugas pengguna dan kontrak data, kemudian pilih gaya antara muka yang boleh dilaksanakan oleh klien dan diselenggara oleh pasukan. Uji respons biasa, input yang cacat, bukti kelayakan yang tamat tempoh, kebenaran, penomboran halaman dan had masa. Pastikan contoh sentiasa terkini dan tunjukkan ralat yang konkrit. Apabila menyepadukan perkhidmatan pihak ketiga, baca had penggunaan, dasar data dan notis perubahannya; titik akhir yang mudah digunakan tetap merupakan kebergantungan yang boleh gagal.