Praktik 'Terbaik' untuk respons POST yang tenang


217

Jadi tidak ada yang baru di sini saya hanya mencoba untuk mendapatkan klarifikasi dan sepertinya tidak dapat menemukan di posting lain

Saya membuat sumber daya baru dengan tenang, katakan:

/books (POST)

dengan tubuh:

{
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

Saya tahu bahwa saya harus mengembalikan 201 (Dibuat) dengan header Lokasi sumber daya baru:

Location: /books/12345

Pertanyaan yang sepertinya tidak bisa saya jawab sendiri adalah apa yang harus dikembalikan server di dalam tubuh.

Saya sering melakukan respons seperti ini:

{
  id: 12345,
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

Saya melakukan ini karena beberapa alasan:

  1. Saya telah menulis api untuk kerangka ujung depan seperti angularjs. Dalam kasus khusus saya, saya menggunakan sumber daya sudut dan saya sering hanya perlu id untuk sumber daya untuk menemukannya. Jika saya tidak mengembalikan id di badan respons, saya harus menguraikannya keluar dari header Lokasi.
  2. Dalam GET semua buku saya biasanya mengembalikan seluruh objek bukan hanya id. Dalam hal ini kode klien saya tidak harus membedakan dari mana mendapatkan id dari (header atau badan lokasi).

Sekarang saya tahu saya benar-benar berada di daerah abu-abu di sini, tetapi kebanyakan orang mengatakan bahwa mengembalikan seluruh sumber daya adalah praktik yang 'buruk'. Tetapi bagaimana jika server mengubah / menambahkan informasi ke sumber daya. Itu pasti menambahkan id, tetapi mungkin juga menambahkan hal-hal lain seperti cap waktu. Jika saya tidak mengembalikan seluruh sumber daya, apakah lebih baik melakukan POST, mengembalikan id, lalu meminta klien melakukan GET untuk mendapatkan sumber daya baru.


Saya pribadi lebih suka badan kosong untuk tanggapan POST. Tidakkah seharusnya nilai header lokasi tenang menjadi URI (pengidentifikasi sumber daya unik)? Jadi mungkin sebaiknya Anda menggunakannya sebagai ID dan tidak menguraikannya untuk mengetahui ID internal server. IMO, RESTful API konsumen harus menavigasi menggunakan hyperlink yang disediakan dan tidak membangun jalur, menebak di mana server tertentu menempatkan sumber daya ... Dan setelah semua, bukankah klien sudah tahu keadaan sumber daya yang baru saja dibuat? Mengulangi itu membuang-buang sumber daya jaringan.
ch4mp

1
Untuk Buat / Sisipkan, Status 201 - CREATED, Header Location → localhost: 8080 / karyawan / 1 (Lihat: di sini )
Hassan Tareq

Jawaban:


129

Mengembalikan seluruh objek pada pembaruan sepertinya tidak terlalu relevan, tapi saya hampir tidak bisa melihat mengapa mengembalikan seluruh objek saat dibuat akan menjadi praktik buruk dalam kasus penggunaan normal. Ini akan berguna setidaknya untuk mendapatkan ID dengan mudah dan mendapatkan cap waktu ketika relevan. Ini sebenarnya adalah perilaku default yang didapat ketika perancah dengan Rails.

Saya benar-benar tidak melihat keuntungan dari hanya mengembalikan ID dan melakukan permintaan GET setelahnya, untuk mendapatkan data yang bisa Anda dapatkan dengan POST awal Anda.

Bagaimanapun, selama API Anda konsisten, saya pikir Anda harus memilih pola yang paling sesuai dengan kebutuhan Anda. Tidak ada cara yang benar tentang cara membangun REST API, imo.


26
Saya tahu ini sudah tua, tapi saya bisa memberikan argumen yang meyakinkan untuk menggunakan GET setelah POST Anda. Dalam spesifikasi http / 1.1, setiap alat historis dapat mengabaikan pengaturan cache yang dikembalikan dari respons GET Anda ... jadi jika pengguna Anda menggunakan tombol kembali di browser untuk kembali ke halaman ini setelah Anda memperbaruinya dengan POST, ia dapat menggunakan basi data dalam cache dari GET asli. Jadi jika Anda menggunakan kembali GET maka Anda dapat memperbarui cache dan mendapatkan snapshot yang lebih baik tentang bagaimana halaman terlihat ketika mereka pergi ...
Shaded

8
@Diarsir Jika API dirancang untuk digunakan oleh aplikasi juga, maka argumen Anda untuk membuat dua permintaan tidak berlaku. Di sana, Anda biasanya menyimpan data dengan menyimpan objek dari tipe model dalam memori - yang biasanya dilakukan dengan respons untuk permintaan POST. Dan mengenai browser, respons pada permintaan POST tidak terlalu sakit selama masih ada titik akhir GET api.
Jeehut

Saya berlangganan apa yang dinyatakan Daniel di sini. Bahkan jika Anda memeriksa kerangka kerja matang seperti Data Musim Semi, mereka selalu mengembalikan seluruh objek setelah bertahan. Saya pikir ini adalah praktik yang baik, karena pada klien Anda, Anda akan menyimpan pulang-pergi server untuk mendapatkan informasi yang sama
frandevel

205

Mengembalikan objek baru sesuai dengan prinsip REST dari "Uniform Interface - Manipulasi sumber daya melalui representasi." Objek lengkap adalah representasi keadaan baru dari objek yang telah dibuat.

Ada referensi yang sangat bagus untuk desain API, di sini: Praktik Terbaik untuk Merancang API Tenang Pragmatis

Ini mencakup jawaban atas pertanyaan Anda di sini: Pembaruan & pembuatan harus mengembalikan representasi sumber

Ia mengatakan:

Agar pengguna API tidak perlu menabrak API lagi untuk representasi yang diperbarui, minta API mengembalikan perwakilan yang diperbarui (atau dibuat) sebagai bagian dari respons.

Tampak pragmatis bagi saya dan cocok dengan prinsip REST yang saya sebutkan di atas.


6
bagaimana kalau mengembalikan seluruh set objek yang relevan? dengan cara ini, kemungkinan penyortiran dapat dilakukan di sisi server, dan memudahkan implementasi front-end
phil294

2
Tetapi praktik terbaik ini bukan yang terbaik. Penulis menyatakan bahwa HATEOAS, yang penting sama dengan prinsip-prinsip lain, tidak boleh digunakan karena "itu belum siap". HATEOAS tidak akan pernah "siap", karena semua prinsip RESTful hanyalah prinsip desain arsitektur, bukan implementasi spesifik. Referensi yang dikutip adalah tentang visi penulis tentang RESTful API, yang sama sekali tidak TENANG karena menjatuhkan HATEOAS. Itu sebabnya ini bukan referensi terbaik :)
marcinn

1
@marcinn - Anda akan perhatikan bahwa pertanyaan asli memiliki tanda kutip di sekitar 'Terbaik', saya kira karena ada banyak pendapat di bidang ini. Referensi yang saya tunjuk adalah sesuatu yang menurut saya praktis. Jika Anda memiliki referensi yang lebih baik, silakan bagikan. Saya selalu terbuka untuk belajar lebih banyak.
grahamesd

@grahamesd Implementasi adalah hal yang berbeda dari desain / pola arsitektur. Tidak ada yang bisa berharap bahwa HATEOAS akan siap suatu hari nanti, tetapi ada kemungkinan seseorang akan membuat implementasi yang dapat diterima oleh banyak orang. Vinay juga menulis tentang memetakan metode http ke URL dan operasi spesifik (CRUD), menyatakan bahwa versi dengan awalan url lebih pragmatis, menulis bahwa pemfilteran dengan parameter kueri adalah cara untuk pergi ... baik-baik saja, tetapi semua ini memiliki sedikit untuk lakukan dengan arsitektur yang tenang. Dia menulis tentang semacam kontrak. Itu bagus untuk HTTP API, tetapi jangan menyebutnya RESTful.
marcinn

@grahamesd Berikut adalah beberapa posting yang menjelaskan hal ini: - medium.com/@andrea.chiarelli/… - restfulapi.net
marcinn
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.