Haruskah RESTful API menyediakan data untuk seluruh formulir?

13

Katakanlah saya memiliki aplikasi web JavaScript yang sepenuhnya menggunakan RESTful API untuk data.

Katakanlah aplikasi ini memiliki formulir data, dan katakanlah saya sedang mengedit catatan di / produk / 12345. Saat membangun formulir, saya membuat permintaan RESTful ke / produk / 12345 dan mendapatkan data JSON:

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27
}

Jadi, formulir saya jelas memiliki daftar dropdown untuk memilih tenaga penjualan. Saya perlu mengisi daftar ini. Dari mana seharusnya data berasal? Apa pendekatan yang paling umum?

Apakah masuk akal untuk menjadikannya bagian dari respons permintaan / produk / 12345?

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27,
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ]
}

Bagaimana dengan saat membuat catatan baru? Haruskah API saya juga menanggapi GET / produk / baru, dengan yang berikut ini?

{
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ],
  "categories": [
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
  ],
  "etc": [ ... ]
}

api rest forms

— Chad Johnson
sumber

tolong jangan pernah gunakan permintaan GET untuk membuat sesuatu. Titik akhir Anda harus / bukan produk / produk / baru . Untuk membuat produk baru, Anda harus mengirim permintaan PUT ke titik akhir itu.

— Kerem Baydoğan

Ini bukan menciptakan apa pun. Ini murni permintaan untuk data yang ada atau templat untuk catatan baru yang belum disimpan.

— Chad Johnson

oh maaf, sekarang saya mengerti maksud Anda. apa pun titik akhir produk tidak boleh bertanggung jawab untuk menyediakan produk templat atau daftar nilai untuk drop-down formulir pembuatan produk. seperti yang dikatakan @Dan, buat saja titik akhir yang terpisah dan gunakan header caching sehingga browser Anda dapat menembolok nilai drop-down untuk kinerja.

— Kerem Baydoğan

6

Saya condong ke arah titik akhir yang sangat sederhana dan fokus sempit. Saya mengharapkan permintaan di beberapa lokasi seperti / sales_users yang mengembalikan semua pengguna penjualan.

GET / sales_users:

[
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
]

Demikian pula, jika Anda akan memiliki daftar kategori, saya akan menambahkan titik akhir yang terpisah untuk itu.

DAPATKAN / kategori:

[
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
]

Saya tidak akan membangun GET / produk / baru. Sebaliknya, saya akan membuat formulir di aplikasi Anda untuk menangani penambahan produk baru yang mengetahui permintaan yang sesuai untuk mengisi daftar (mis., GET / kategori, GET / sales_users, dll.).

— Dan Lyons
sumber

3

Dengan asumsi bahwa daftar tenaga penjualan relatif statis, saya akan berpikir Anda ingin panggilan API terpisah /salesusersyang dapat Anda panggil sekali (pada formulir memuat, dll.) Dan simpan sehingga Anda tidak perlu meminta kembali data ini setiap waktu. Ingat di REST, Anda mengatur API Anda di sekitar sumber daya, dan tenaga penjualan secara logis memisahkan sumber daya dari produk.

Demikian juga, saat menelepon /product/new, Anda hanya ingin mengirimkan data untuk produk baru, yang mungkin menyertakan id sales_user, tetapi tidak lebih. Perubahan ke sales_user itu sendiri akan menjadi panggilan terpisah.

— Dan1701
sumber