Kaedah dan Kod HTTP

Kaedah HTTP

digunakan untuk menunjukkan operasi klien API yang ingin melaksanakan sumber yang diberikan. Setiap kaedah HTTP sepadan dengan operasi tertentu, seperti membuat, membaca, mengemaskini atau memadam sumber, dan setiap permintaan untuk API REST mesti memasukkan kaedah HTTP.

Prinsip kerja protokol HTTP ialah klien menghantar permintaan kepada pelayan, dan pelayan bertindak balas terhadap permintaan ini. Kami menghantar permintaan HTTP dengan menggunakan kaedah HTTP yang berbeza (kadang -kadang dipanggil kata kerja HTTP) untuk melakukan operasi CRUD (penciptaan, membaca, mengemas kini, memadam). Dapatkan dan pos adalah kaedah HTTP yang paling biasa digunakan, tetapi terdapat lebih banyak kaedah HTTP untuk belajar. Artikel ini akan memperkenalkan kaedah HTTP yang berbeza dan bagaimana menggunakannya semasa membina dan menggunakan API Web.

Kaedah 9 HTTP yang harus anda fahami

<.> 1. Dapatkan kaedah

Jika kita mahu mengambil data dari sumber (seperti laman web, pelayan, atau API), kami akan menghantarnya mendapatkan permintaan. Sebagai contoh, jika kami mahukan senarai pelanggan atau pelanggan tertentu, kami akan menghantar permintaan GET ke pelayan.

Oleh kerana kaedah GET tidak boleh mengubah data pada sumber, tetapi hanya membacanya (baca sahaja), ia dianggap sebagai kaedah keselamatan. Di samping itu, kaedah GET adalah kuasa.

Bagaimana menggunakan kaedah GET untuk menguji API?

Apabila kita mahu menguji API, kaedah yang paling biasa kita ialah kaedah GET. Oleh itu, kami mengharapkan situasi berikut:

Jika sumber boleh diakses, API akan mengembalikan 200 kod status untuk menunjukkan "OK".

Sebagai tambahan kepada 200 kod status, pelayan biasanya mengembalikan teks tindak balas dalam format XML atau JSON. Sebagai contoh, kami mengharapkan [/ahli] Endpoint untuk mengembalikan senarai ahli dalam format XML atau JSON.

Jika pelayan tidak menyokong titik akhir, pelayan akan mengembalikan kod status 404, menunjukkan "tidak dijumpai."

Jika kami menghantar permintaan dengan tatabahasa yang salah, pelayan akan mengembalikan 400 kod status untuk menunjukkan "permintaan yang salah".

<.> 2. Kaedah pos

Kaedah pos mewujudkan sumber baru di hujung belakang (pelayan). Teks permintaan membawa data yang ingin kami hantar ke pelayan. Ia bukan kaedah keselamatan atau kuasa. Kami tidak mengharapkan hasil yang sama untuk setiap permintaan penghantaran. Sebagai contoh, dua permintaan pos yang sama akan mewujudkan dua sumber setara baru dengan data yang sama dan ID sumber yang berbeza.

Apabila menghantar permintaan pos ke pelayan, kami mengharapkan situasi berikut: Sebaik -baiknya, jika permintaan pos mewujudkan sumber baru di hujung yang lain, respons harus mempunyai Kod Negeri 201, yang bermaksud "dicipta".

Kadang -kadang pelaksanaan permintaan pos tidak akan mengembalikan sumber dalam URL yang diberikan;

bagaimana untuk menguji postpoint postpoint

Oleh kerana kaedah pos mencipta data, kita mesti mengubah data dengan teliti; Di samping itu, pastikan untuk memadamkan sumber yang dibuat selepas ujian selesai.

Berikut adalah beberapa cadangan yang boleh kita gunakan untuk menguji API yang menggunakan kaedah pos:

Gunakan kaedah pos untuk membuat sumber, ia harus mengembalikan kod negeri 201.

Jalankan kaedah GET untuk memeriksa sama ada sumber itu berjaya dibuat. Anda perlu mendapatkan 200 kod status dan bertindak balas terhadap sumber yang telah dibuat.

menggunakan data yang salah atau salah untuk melaksanakan kaedah pos untuk memeriksa sama ada operasi gagal.

<.> 3. Letakkan kaedah

Menggunakan kaedah permintaan PUT, kami boleh mengemas kini sumber sedia ada dengan menghantar data yang dikemas kini sebagai kandungan teks permintaan ke pelayan. Kaedah meletakkan mengemas kini sumber dengan menggantikannya sepenuhnya. Jika ia digunakan untuk koleksi sumber, ia akan menggantikan keseluruhan koleksi, jadi sila gunakan dengan teliti. Pelayan akan mengembalikan kod status 200 atau 204 selepas berjaya mengemas kini sumber sedia ada.

Bagaimana menggunakan kaedah PUT untuk menguji API?

Kaedah meletakkan kuasa, dan lain -lain, ia mengubah keseluruhan sumber, jadi untuk menguji tingkah laku, kami memastikan operasi berikut:

Hantar permintaan Put ke pelayan berkali -kali, dan ia harus sentiasa mengembalikan hasil yang sama.

Apabila pelayan melengkapkan permintaan PUT dan mengemas kini sumber, respons harus mempunyai kod status 200 atau 204.

Selepas pelayan melengkapkan permintaan PUT, permintaan GET dikeluarkan untuk memeriksa sama ada data mengenai sumber telah dikemas kini dengan betul.

Jika input tidak sah atau formatnya adalah ralat, sumbernya tidak dibenarkan.

<.> 4. Patch Method

Patch adalah satu lagi kaedah HTTP yang luar biasa. Sama seperti Put, Patch mengemas kini sumber, tetapi hanya mengemas kini data, tidak semua kemas kini. Sebagai contoh, atas sebab -sebab yang lebih tepat, permintaan pelanggan/{customerId} akan mengemas kini bidang dalam entiti pelanggan dalam sumber. Walau bagaimanapun, kaedah patch mengemas kini medan yang disediakan oleh entiti pelanggan. Umumnya, pengubahsuaian ini harus menjadi format standard, seperti JSON atau XML. Bagaimana untuk menguji API dengan kaedah patch?

Untuk menguji API dengan menggunakan kaedah patch, sila ikuti langkah -langkah yang dibincangkan dalam artikel ini untuk menguji API dengan kaedah PUT dan POST. Pertimbangkan hasil berikut:

Hantar permintaan patch ke pelayan;

Jalankan mendapatkan permintaan dan sahkan sama ada kandungan telah dikemas kini dengan betul.

Jika permintaan itu tidak betul atau formatnya tidak betul, operasi mesti gagal.

<.> 5. Padam kaedah

Seperti namanya, padamkan sumber. Kaedah padam adalah kuasa, tidak kira berapa banyak panggilan dipanggil, ia mengembalikan hasil yang sama.

Kebanyakan API sentiasa mengembalikan kod negeri 200.

Bagaimana untuk menguji titik akhir padam? Apabila memadam beberapa kandungan pada pelayan, kita harus berhati -hati. Kami memadam data, yang penting. Pertama, pastikan data padam boleh diterima, dan kemudian lakukan operasi berikut:

panggil kaedah pos untuk membuat sumber baru. Jangan gunakan data sebenar untuk menguji Padam. Sebagai contoh, buat pelanggan baru terlebih dahulu, dan kemudian cuba memadam pelanggan yang baru anda buat.

Hantar permintaan padam untuk sumber tertentu. Sebagai contoh, permintaan [padam] /pelanggan /{customer-id} memadam pelanggan dengan ID pelanggan yang ditetapkan.

Panggil kaedah GET untuk pelanggan yang dipadam, dan ia harus kembali 404 kerana sumber tidak lagi wujud.

<.> 6. Kaedah kepala

Kaedah kepala adalah serupa dengan kaedah GET. Tetapi ia tidak mempunyai teks tindak balas, jadi jika ia mengembalikan teks tindak balas dengan salah, ia mesti diabaikan. Sebagai contoh, [GET] /Pelanggan Endpoint mengembalikan senarai pelanggan dalam teks responsnya. Di samping itu, [kepala] /pelanggan juga melakukan operasi yang sama, tetapi ia tidak kembali ke senarai pelanggan. Sebelum meminta mendapatkan titik akhir, kami boleh menghantar permintaan kepala untuk menentukan saiz fail atau data yang kami muat turun. Oleh itu, kaedah kepala adalah selamat dan kuasa.

bagaimana untuk menguji titik akhir kepala

Salah satu kelebihan kaedah kepala adalah selagi API menyokongnya, kita boleh menguji sama ada pelayan boleh didapati dan boleh diakses, dan ia jauh lebih cepat daripada kaedah GET kerana ia tidak bertindak balas terhadap teks tersebut . Kami berharap kod status yang diperoleh dari API adalah 200. Sebelum kaedah HTTP masing -masing, kita boleh menggunakan kaedah kepala untuk menguji API.

<.> 7. Kaedah pilihan

Kami menggunakan kaedah ini untuk mendapatkan maklumat mengenai pilihan komunikasi yang mungkin (kaedah HTTP yang dibenarkan) untuk diberikan dalam pelayan, atau menggunakan nombor bintang untuk merujuk kepada keseluruhan pelayan. Kaedah ini selamat dan berkuasa.

Pelbagai pelayar menggunakan kaedah pilihan untuk memeriksa sama ada operasi CORS (perkongsian sumber yang dihantar) pada API sasaran adalah terhad.

bagaimana untuk menguji pilihan endpoint

Mengikut sama ada pelayan menyokong kaedah pilihan, kami boleh menggunakan kaedah pilihan untuk menguji bilangan kesalahan maut pelayan. Cubalah, sila pertimbangkan perkara berikut: Hantar permintaan pilihan dan periksa tajuk dan kod status yang dikembalikan.

Uji kegagalan sumber yang tidak menyokong kaedah pilihan.

<.> 8. Kaedah jejak

Kaedah jejak digunakan untuk diagnosis. Ia menggunakan teks permintaan yang sama bahawa teks permintaan kepada pelayan sebelum klien membuat ujian belakang cincin, dan kod respons yang berjaya adalah 200 OK. Kaedah jejak adalah selamat dan kuasa.

Kaedah jejak mungkin berbahaya kerana ia mungkin bocor kelayakan. Peretas boleh menggunakan serangan pelanggan, termasuk tajuk Pengesahan Identiti Dalaman.

Bagaimana menggunakan kaedah jejak untuk menguji API?

Hantar permintaan HTTP standard, seperti permintaan GET /API /Status

Gantikan Get To Trace dan hantar lagi.

Semak kandungan pelayan. Jika respons mempunyai maklumat yang sama dengan permintaan asal, fungsi jejak diaktifkan dalam pelayan dan kerja adalah normal.

<.> 9. Sambungkan kaedah

Kaedah Sambungkan digunakan untuk mewujudkan hubungan akhir -untuk -antara pelanggan dan pelayan. Ia membina sambungan dua jalan di antara mereka, seperti terowong. Sebagai contoh, kita boleh menggunakan kaedah ini untuk menghantar fail besar antara pelanggan dan pelayan.

Kaedah http Bandingkan

Ringkasan Kaedah CRUD Menerima permintaan Kuasa Teks Permintaan dan Keselamatan Lain Dapatkan bacaan sumber atau sumber sumber tunggal Letakkan satu kemas kini masa keseluruhan kemas kini sumber adalah ya Adakah mungkin untuk mencipta penciptaan sumber baru? Sebahagian daripada kemas kini sumber pembaharuan patch Padam Padam Sumber, adakah atau tidak? Pilihan memperoleh maklumat mengenai operasi yang dibenarkan, adakah ia dibaca? Pemerolehan kepala bacaan metadata endpoint Jejak digunakan untuk mendiagnosis tujuan membaca Connect mewujudkan sambungan dua jalan antara klien dan sumber -no-

Atas ialah kandungan terperinci Kaedah dan Kod HTTP. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!