Biasanya saya akan mengembalikan jumlah rekaman sebagai metadata. Saya tidak yakin apakah itu praktik REST yang normal, tetapi tidak banyak data tambahan, dan sangat tepat. Biasanya ada pagination untuk banyak layanan, tidak praktis untuk mengembalikan resultset besar sekaligus. Secara pribadi saya kesal ketika ada pagination untuk set hasil kecil .. Jika kosong, kembalikan number_of_records : 0
dan buku sebagai daftar / array kosong books : []
.
{
meta: {
number_of_records : 2,
records_per_page : 10,
page : 0
},
books : [
{id:1},
{id:27}
]
}
EDIT (beberapa tahun kemudian): Jawaban dari Martin Wickman jauh lebih baik, inilah "penjelasan singkat" mengapa.
Ketika berhadapan dengan pagination selalu ingat kemungkinan konten atau pemesanan berubah. Seperti, permintaan pertama datang, 24 hasil, Anda kembali pertama 10. Setelah itu, "buku baru" dimasukkan dan sekarang Anda memiliki 25 hasil, tetapi dengan permintaan asli itu akan datang dipesan di tempat ke-10. Ketika pengguna pertama meminta halaman ke-2, ia tidak akan mendapatkan "buku baru". Ada beberapa cara untuk mengatasi masalah seperti itu, seperti menyediakan "id permintaan" yang harus dikirim dengan panggilan API berikut, kemudian mengembalikan halaman berikutnya dari set hasil "lama", yang harus disimpan entah bagaimana dan terikat dengan "permintaan id". Alternatifnya adalah menambahkan bidang seperti "daftar hasil diubah sejak permintaan pertama".
Secara umum, jika Anda bisa, cobalah untuk melakukan upaya ekstra dan menghindari pagination. Pagination adalah status tambahan yang dapat dimutasi dan melacak perubahan seperti itu rawan kesalahan, terlebih lagi karena server dan klien perlu menanganinya.
Jika Anda memiliki terlalu banyak data untuk diproses sekaligus , pertimbangkan untuk mengembalikan "daftar id" dengan semua hasil dan detail untuk sebagian daftar itu, dan berikan panggilan API untuk sumber daya multi_get / get_by_id_list.