Dengan buku REST vs Permintaan Terlalu Banyak

Dari komentar Roy Fielding pada artikelnya sendiri mengutuk apis REST palsu :

API yang benar-benar tenang seperti hypertext. Setiap unit informasi yang dapat dialamatkan membawa alamat, baik secara eksplisit (misalnya, atribut tautan dan id) atau secara implisit (misalnya, diturunkan dari definisi jenis media dan struktur representasi). Hasil kueri diwakili oleh daftar tautan dengan informasi ringkasan, bukan oleh array representasi objek (kueri bukan pengganti untuk identifikasi sumber daya).

Ini berarti bahwa jika Anda perlu, katakanlah, kueri untuk daftar 100 pengguna yang paling baru masuk, dan menampilkan nama dan email mereka, Anda harus terlebih dahulu melakukan GETkueri untuk daftar hasil, yang akan (pada dasarnya) menjadi daftar elemen tautan, dengan setiap objek tautan berisi URI sumber daya pengguna. Anda kemudian perlu membuat 100 permintaan lagi GET - satu untuk setiap sumber daya pengguna - sebelum Anda benar-benar memiliki data yang Anda butuhkan untuk menampilkan hasil Anda.

Tampaknya sangat tidak efisien. Apakah benar-benar tidak ada cara lain yang benar-benar tenang untuk mendapatkan data yang Anda butuhkan dalam 1 atau 2 permintaan?

Apakah benar-benar tidak ada cara lain yang benar-benar tenang untuk mendapatkan data yang Anda butuhkan dalam 1 atau 2 permintaan?

• Tidak juga
• Tapi jangan terlalu dipikirkan

Seperti biasa, ketika memikirkan REST, ingatlah bahwa ada implementasi referensi (world wide web) yang dapat Anda periksa.

Pertimbangkan portal Amazon - ketika saya membuka bookmark itu dengan cache kosong, saya melihat browser saya membuat permintaan ke 275 sumber daya.

Apakah saya akan mendapatkan latensi yang lebih baik jika semua status itu diambil dalam satu muatan? Iya.

Akankah skala itu? apakah itu skala web? Mungkin tidak. Itu 4,5MB data yang tidak bisa dibagi karena di dalamnya termasuk 1KB yang khusus untuk profil saya. Jika rekan saya di meja sebelah saya juga pergi ke Amazon, dia menarik data yang sama di jaringan.

Uraikan muatan itu menjadi sumber daya yang dapat dialamatkan secara individual, dan tiba-tiba segalanya menjadi jauh lebih baik - kita masing-masing masih mendapatkan personalisasi 1KB, dan kita masing-masing masih memiliki salinan 4,5MB yang di-cache secara lokal, tetapi kita tidak perlu membenturkan jaringan sama sulitnya, karena sebagian besar permintaan kami dilayani oleh cache bersama lokal, alih-alih perlu dirutekan di internet.

Juga, ingatlah bahwa Anda tidak benar-benar memiliki masalah dengan banyak sumber daya , Anda memiliki masalah dengan beberapa permintaan . Itu dapat dikurangi dengan menggunakan HTTP / 2.0 Push Promises , dengan server secara proaktif mendorong representasi yang bisa di-cache. Mungkin - server stateless tidak tahu apa yang telah di-cache klien, dan TLS menyarankan bahwa caching di perantara bukanlah prioritas ....

Ini berarti bahwa jika Anda perlu, misalnya, meminta daftar 100 pengguna yang paling baru masuk, dan menampilkan nama dan email mereka, Anda harus terlebih dahulu melakukan permintaan GET untuk daftar hasil, yang akan (pada dasarnya ) menjadi daftar elemen tautan, dengan setiap objek tautan berisi URI sumber daya pengguna. Anda kemudian perlu membuat 100 lebih banyak permintaan GET - satu untuk setiap sumber daya pengguna - sebelum Anda benar-benar memiliki data yang Anda butuhkan untuk menampilkan hasil Anda.

Tentu saja, jika Anda melakukan ini dalam html, representasi Anda dari pengguna yang paling baru masuk mungkin akan menjadi dokumen dengan daftar atau daftar nama dan alamat email dan tautan ke sumber daya tersebut. Ta-da.

Jangan sampai ketinggalan jejak pengamatan ini oleh Fielding.

Itu tidak berarti bahwa saya pikir semua orang harus merancang sistem mereka sendiri sesuai dengan gaya arsitektur REST. REST ditujukan untuk aplikasi berbasis jaringan berumur panjang yang menjangkau banyak organisasi. Jika Anda tidak melihat perlunya kendala, maka jangan menggunakannya.

EDIT

dapatkah saya membuat argumen yang sama untuk representasi JSON? yaitu, jika sumber daya yang dimaksud adalah "100 pengguna yang terakhir masuk" daripada hasil kueri yang diparameterisasi, dapatkah saya mengembalikan data itu sendiri alih-alih tautan sumber daya? jika tidak, mengapa? mengapa JSON pada dasarnya berbeda dari HTML dalam hal ini?

Bagaimana mereka sama: mengemas lebih banyak data ke dalam "daftar hasil" menghemat biaya permintaan tambahan, sementara kompromi penskalaan. Jenis media spesifik yang Anda gunakan untuk representasi tidak masalah - setidaknya, sejauh yang saya tahu.

Bagaimana mereka berbeda: HTML adalah format hypermedia, dan JSON tidak - implementasi klien standar apa pun yang akrab dengan spesifikasi HTML akan tahu cara menemukan tautan dalam dokumen HTML, yang mendukung opsi seperti pra-pengambilan. JSON tidak memiliki standarisasi itu - Anda perlu informasi out-of-band tentang struktur data untuk memahami di mana tautan berada dalam representasi JSON. HAL akan lebih cocok dengan HTML dalam hal ini; perbedaan utama antara HAL dan HTML adalah adopsi; HTML memiliki awal 20 tahun ke depan?

Untuk wawasan tambahan, Anda mungkin juga mempertimbangkan untuk meninjau Format Sindikasi Atom , yang menjelaskan Entri dan Umpan (daftar Entri), terutama aturan untuk entri atom:, yang dapat diakses melalui sumber daya yang berdiri sendiri, atau melalui sumber daya umpan.