Apakah Prinsip Reka Bentuk API REST?

Prinsip Reka Bentuk API REST termasuk definisi sumber, reka bentuk URI, penggunaan kaedah HTTP, penggunaan kod status, kawalan versi, dan benci. 1. Sumber harus diwakili oleh kata nama dan dikekalkan pada hierarki. 2. Kaedah HTTP harus mematuhi semantik mereka, seperti GET digunakan untuk mendapatkan sumber. 3. Kod status hendaklah digunakan dengan betul, seperti 404 bermakna sumber tidak wujud. 4. Kawalan versi boleh dilaksanakan melalui URI atau header. 5. Boots Operasi Pelanggan Hateoas melalui pautan sebagai tindak balas.

Pengenalan

Rest Prinsip Reka Bentuk API, ini adalah topik yang banyak pemaju suka dan benci. Kenapa awak katakan begitu? Kerana API REST ada di mana -mana dalam pembangunan web moden, prinsip reka bentuknya adalah mudah dan kompleks, begitu mudah sehingga semua orang dapat bermula, begitu kompleks bahawa pemaju kanan juga mungkin jatuh ke dalam pemikiran yang mendalam. Hari ini kita akan bercakap mengenai reka bentuk API REST. Selepas bercakap, anda akan mempunyai pemahaman yang lebih mendalam tentang cara merancang API REST yang elegan dan praktikal.

Konsep asas rehat

Rehat, Nama Penuh Perwakilan Pemindahan Negeri, adalah gaya seni bina yang digunakan untuk merancang aplikasi rangkaian. Roy Fielding mencadangkan konsep ini pada tahun 2000, dan idea terasnya adalah untuk melaksanakan operasi sumber melalui protokol HTTP. Ringkasnya, REST merawat semua kandungan sebagai sumber, setiap sumber dikenal pasti oleh URI yang unik, dan beroperasi pada sumber melalui kaedah HTTP (seperti GET, POST, PUT, DELETE).

Sebagai contoh, katakan kami mempunyai sistem blog di mana jawatan blog boleh dianggap sebagai sumber, maka API untuk mendapatkan jawatan tertentu boleh direka sebagai:

 Dapatkan /artikel /{artikelID}

Ini adalah permintaan mudah untuk mendapatkan artikel dengan ID tertentu melalui URI.

Inti Prinsip Reka Bentuk API REST

Definisi sumber dan reka bentuk URI

Dalam API REST, sumber adalah konsep teras. Setiap sumber harus mempunyai URI yang unik untuk mengenalinya. Semasa merancang URI, anda perlu mengikuti beberapa prinsip:

• Gunakan kata nama bukan kata kerja : URI harus mewakili sumber itu sendiri, bukan operasi. Sebagai contoh, /users harus digunakan bukannya /getUsers .
• Simpan Hierarki : URI harus mencerminkan hubungan antara sumber. Sebagai contoh, artikel pengguna boleh diwakili sebagai /users/{userId}/articles .

Reka bentuk URI yang baik bukan sahaja menjadikan API lebih mudah difahami, tetapi juga lebih mudah untuk dikekalkan. Sebagai contoh, jika kita ingin mendapatkan semua artikel pengguna tertentu, kita boleh merancangnya seperti ini:

 GET/USERS/{USERID}/artikel

Penggunaan kaedah HTTP

Kaedah HTTP adalah inti lain dari API REST. Setiap kaedah mempunyai semantik tersendiri:

• Dapatkan : Digunakan untuk mendapatkan sumber
• Catatan : Digunakan untuk menghasilkan sumber baru
• Letakkan : Digunakan untuk mengemas kini sumber
• Padam : Digunakan untuk memadam sumber

Apabila menggunakan kaedah ini, anda perlu memastikan mereka mematuhi spesifikasi HTTP. Sebagai contoh, permintaan GET harus menjadi idempotent, iaitu pelbagai panggilan tidak akan mengubah keadaan sumber.

Penggunaan kod status

Kod Status HTTP adalah cara penting untuk API REST untuk berkomunikasi dengan pelanggan. Kod status biasa adalah:

• 200 Ok : Permintaannya berjaya
• 201 dicipta : Penciptaan sumber berjaya
• 400 permintaan buruk : permintaannya tidak sah
• 404 tidak dijumpai : sumbernya tidak wujud
• 500 Ralat Pelayan Dalaman : Ralat Pelayan Dalaman

Penggunaan kod status yang betul boleh memudahkan pelanggan memahami respons API. Sebagai contoh, apabila pengguna meminta sumber yang tidak wujud, kod status 404 dikembalikan:

 Dapatkan /Artikel /9999
Http/1.1 404 tidak dijumpai

Kawalan versi

Versi API adalah aspek penting dalam reka bentuk rehat. API boleh berubah dari masa ke masa, dan bagaimana untuk mengendalikan perubahan ini tanpa menjejaskan pelanggan sedia ada adalah satu cabaran. Kaedah kawalan versi biasa adalah:

• Kawalan Versi URI : Contoh /v1/users
• Kawalan versi header : Gunakan tajuk tersuai seperti Accept: application/vnd.myapp.v1 json

Saya secara peribadi lebih suka kawalan versi URI kerana ia lebih intuitif dan lebih mudah bagi pelanggan untuk memahami dan menggunakannya.

Hypermedia sebagai enjin aplikasi aplikasi (HATEOAS)

HATEOAS adalah ciri Lanjutan REST, yang membolehkan API membimbing pelanggan ke langkah seterusnya melalui pautan dalam respons. Sebagai contoh, apabila mendapat senarai pengguna, respons mungkin termasuk pautan kepada setiap pengguna:

 {
  "Pengguna": [
    {
      "Id": 1,
      "Nama": "John Doe",
      "Pautan": [
        {
          "rel": "diri",
          "href": "/pengguna/1"
        }
      ]
    }
  ]
}

HATEOAS boleh menjadikan API lebih digambarkan sendiri, dan pelanggan boleh menemui dan menggunakan API secara dinamik berdasarkan pautan dalam respons. Walau bagaimanapun, melaksanakan benci juga meningkatkan kerumitan API, dan memerlukan perdagangan untuk ditimbang sama ada ciri ini benar-benar diperlukan.

Contoh penggunaan

Penggunaan asas

Mari kita lihat contoh API REST yang mudah, katakan kita ingin merancang sistem pengurusan perpustakaan:

 Dapatkan /Buku

Ini mengembalikan senarai semua buku:

 [
  {
    "Id": 1,
    "Tajuk": "The Great Gatsby",
    "Pengarang": "F. Scott Fitzgerald"
  },
  {
    "Id": 2,
    "Tajuk": "Untuk Membunuh Mockingbird",
    "Pengarang": "Harper Lee"
  }
]

Penggunaan lanjutan

Sekarang mari kita lihat contoh yang lebih kompleks, katakan kita ingin melaksanakan fungsi carian buku:

 Dapatkan /Buku? Tajuk = The Great Gatsby

Ini mengembalikan buku dengan tajuk "The Great Gatsby":

 [
  {
    "Id": 1,
    "Tajuk": "The Great Gatsby",
    "Pengarang": "F. Scott Fitzgerald"
  }
]

Kesilapan biasa dan tip debugging

Kesalahan biasa semasa merancang API rehat termasuk:

• Reka bentuk URI tidak konsisten : Sebagai contoh, kadang -kadang menggunakan /users/{userId} dan kadang -kadang menggunakan /user/{userId} , yang menjadikan API berantakan.
• Kod Status Ralat : Sebagai contoh, jika sumber tidak wujud, mengembalikan 500 bukan 404, yang menjadikannya sukar bagi klien untuk mengendalikan ralat.

Kaedah untuk menyahpepijat masalah ini termasuk:

• Menggunakan alat dokumentasi API seperti Swagger atau Postman boleh membantu anda menguji dan mengesahkan ketepatan API anda.
• Pembalakan : Rekod log terperinci di sisi pelayan, yang dapat membantu anda mengesan dan menyelesaikan masalah.

Pengoptimuman prestasi dan amalan terbaik

Dalam aplikasi praktikal, bagaimana untuk mengoptimumkan prestasi API REST adalah topik penting. Berikut adalah beberapa cadangan pengoptimuman:

• Cache : Gunakan HTTP ke tajuk cache seperti Cache-Control dan ETag untuk mengurangkan permintaan yang tidak perlu.
• Paging : Untuk API yang mengembalikan sejumlah besar data, menggunakan paging dapat mengurangkan jumlah data dalam satu permintaan dan meningkatkan kelajuan tindak balas. Contohnya:

 Dapatkan /Buku? Page = 1 & Saiz = 10

• Pemprosesan Asynchronous : Untuk operasi yang memakan masa, pemprosesan tak segerak boleh digunakan untuk meningkatkan kelajuan tindak balas API.

Terdapat beberapa amalan terbaik yang perlu diperhatikan semasa menulis API REST:

• Kebolehbacaan Kod : Gunakan penamaan dan komen yang jelas untuk menjadikan kod lebih mudah difahami dan diselenggarakan.
• Keselamatan : Gunakan HTTPS untuk memastikan keselamatan penghantaran data; Gunakan OAuth atau JWT untuk mencapai pengesahan dan kebenaran.
• Ujian : Tulis ujian automatik untuk memastikan ketepatan dan kestabilan API.

Meringkaskan

Prinsip reka bentuk API yang lain mungkin kelihatan mudah, tetapi mereka bentuk API yang elegan dan praktikal memerlukan pertimbangan yang teliti. Dari definisi sumber, reka bentuk URI, untuk menggunakan kaedah HTTP dan kod status, kepada kawalan versi dan benci, setiap pautan perlu dipertimbangkan dengan teliti. Melalui pengenalan dan contoh artikel ini, saya harap anda dapat mempunyai lebih banyak pemikiran dan amalan ketika merancang API REST, elakkan kesilapan umum, dan meningkatkan prestasi dan kebolehgunaan API.

Atas ialah kandungan terperinci Apakah Prinsip Reka Bentuk API REST?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!