Pembangun Meninggalkan Seni Bina REST Tulen untuk API HTTP yang Lebih Mudah Walaupun Bertentangan dengan Ideal Akademik

Pasukan Komuniti BigGo
Pembangun Meninggalkan Seni Bina REST Tulen untuk API HTTP yang Lebih Mudah Walaupun Bertentangan dengan Ideal Akademik

Dunia pembangunan perisian secara senyap-senyap telah beralih daripada seni bina REST asal Roy Fielding , walaupun terdapat dakwaan meluas tentang pembinaan API RESTful. Apa yang kebanyakan pembangun panggil REST hari ini tidak menyerupai prinsip akademik yang digariskan dalam disertasi Fielding tahun 2000 yang mentakrifkan Representational State Transfer.

Salah Faham Besar Mengenai REST

Isu teras terletak pada salah tafsir asas tentang apa yang sebenarnya dimaksudkan dengan REST. REST tulen memerlukan HATEOAS (Hypermedia as the Engine of Application State), di mana klien menemui tindakan yang tersedia secara dinamik melalui pautan hypermedia yang tertanam dalam respons pelayan. Daripada mengkod keras titik akhir API, klien sepatutnya menavigasi API seperti pengguna melayari laman web - mengikuti pautan yang disediakan oleh pelayan.

Kebanyakan API REST moden sebenarnya adalah sistem gaya RPC yang kebetulan menggunakan kata kerja HTTP dan JSON. Mereka memerlukan dokumentasi yang meluas, URL yang dikod keras, dan gandingan rapat antara klien dan pelayan. Pendekatan ini bercanggah dengan visi Fielding tentang sistem yang boleh ditemui sendiri dan boleh berkembang.

HATEOAS: Prinsip REST yang memerlukan klien menemui tindakan API melalui hiperpautan dalam respons, bukannya bergantung pada dokumentasi

Enam Kekangan REST Fielding:

  • Gunakan Pengecam Sumber Seragam (URI) untuk semua sumber
  • Patuhi piawaian HTTP sedia ada tanpa pengubahsuaian
  • Tentukan pemahaman data melalui jenis media dan pautan, bukan struktur URI
  • Klien tidak sepatutnya mengkodkan laluan URI secara keras tetapi menemuinya secara dinamik
  • Klasifikasi dalaman pelayan mesti tidak kelihatan kepada klien
  • Klien hanya memerlukan satu titik masuk dan pengetahuan jenis media standard

Mengapa Pembangun Memilih Pragmatisme Berbanding Kemurnian

Komuniti sebahagian besarnya telah menerima penyimpangan ini atas sebab praktikal. Membina API yang benar-benar RESTful dengan HATEOAS mewujudkan overhed dan kerumitan yang ketara yang difikirkan oleh banyak pasukan sebagai tidak wajar. Beban kognitif untuk mencipta klien yang dipacu hypermedia sering melebihi faedah teori gandingan longgar dan kebolehkembangan.

Penggunaan meluas gaya yang lebih mudah seperti RPC melalui HTTP mungkin boleh dikaitkan dengan pertukaran praktikal dalam perkakas dan pengalaman pembangun.

Alat seperti OpenAPI dan Swagger telah memudahkan untuk menjana kod klien, mencipta dokumentasi, dan mengesahkan permintaan untuk API HTTP tradisional. Keuntungan produktiviti segera ini terbukti lebih berharga kepada kebanyakan pasukan berbanding faedah seni bina abstrak REST tulen.

Ciri-ciri Biasa API "REST" (Sebenarnya Bukan RESTful):

  • JSON melalui HTTP dengan operasi CRUD
  • Dipetakan kepada kata kerja POST/GET/PUT/DELETE
  • Template URI yang dikodkan keras seperti /users/{id}/orders
  • Memerlukan dokumentasi API yang ekstensif
  • Gandingan ketat antara klien dan pelayan
  • Tiada kawalan hipermedia atau penemuan pautan

Pengecualian Pelayar

Menariknya, pelaksanaan paling berjaya prinsip REST berlaku setiap hari melalui pelayar web. Apabila anda mengklik pautan di laman web, anda sedang mengalami HATEOAS dalam tindakan - pelayar menemui tindakan yang tersedia melalui hiperpautan tanpa pengetahuan awal tentang struktur tapak. Ini berfungsi kerana manusia menyediakan kecerdasan untuk mentafsir dan menavigasi hypermedia.

Walau bagaimanapun, model manusia-dalam-gelung ini tidak diterjemahkan dengan baik kepada komunikasi mesin-ke-mesin, di mana klien automatik memerlukan antara muka yang boleh diramal dan didokumentasikan dengan baik untuk berfungsi dengan boleh dipercayai.

Bergerak Ke Hadapan dengan Terminologi Jujur

Daripada meneruskan pertempuran semantik mengenai definisi REST, ramai pembangun kini lebih suka memanggil ciptaan mereka sebagai API HTTP atau API JSON. Pelabelan jujur ini mengelakkan bagasi akademik sambil menyampaikan dengan jelas apa yang sebenarnya disediakan oleh sistem.

Industri pada dasarnya telah mengundi dengan papan kekunci mereka, memilih penyelesaian praktikal berbanding kemurnian seni bina. Walaupun puris mungkin meratapi penyimpangan daripada visi Fielding ini, penggunaan meluas API seperti-REST menunjukkan mereka lebih baik melayani keperluan pembangunan dunia sebenar berbanding rakan sejawat mereka yang betul secara akademik.

Rujukan: Most RESTful APIs aren't really RESTful