Apa kata kerja dan tindakan RESTful url terbaik / umum?

86

Saya mencoba menemukan beberapa info tentang tindakan url RESTful terbaik dan paling umum.

misalnya, url apa yang Anda gunakan untuk menampilkan detail suatu item, untuk mengedit item, memperbarui, dll.

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

hmm. terima kasih kepada siapa pun yang membantu :)

rest 
— Pure.Krome
sumber

Jawaban:

174

Gunakan URL untuk menentukan objek Anda, bukan tindakan Anda:

Perhatikan apa yang pertama kali Anda sebutkan tidak tenang:

/questions/show/<whatever>

Sebagai gantinya, Anda harus menggunakan URL Anda untuk menentukan objek Anda:

/questions/<question>

Kemudian Anda melakukan salah satu operasi di bawah ini pada sumber daya itu.

DAPATKAN:

Digunakan untuk mendapatkan sumber daya, membuat kueri daftar sumber daya, dan juga untuk menanyakan informasi hanya-baca pada sumber daya.

Untuk mendapatkan sumber pertanyaan:

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

Untuk mendaftar semua sumber pertanyaan:

GET /questions HTTP/1.1
Host: whateverblahblah.com

POS:

Digunakan untuk membuat sumber daya.

Perhatikan bahwa berikut ini adalah kesalahan:

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Jika URL belum dibuat, Anda tidak boleh menggunakan POST untuk membuatnya saat menentukan nama. Ini akan menghasilkan kesalahan sumber daya tidak ditemukan karena belum ada. Anda harus MENEMPATKAN sumber daya di server terlebih dahulu. Anda dapat berargumen bahwa dengan membuat pertanyaan baru, Anda juga memperbarui sumber / pertanyaan karena sekarang akan menghasilkan satu pertanyaan lagi dalam daftar pertanyaannya.

Anda harus melakukan sesuatu seperti ini untuk membuat sumber daya menggunakan POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Perhatikan bahwa dalam kasus ini nama sumber daya tidak ditentukan, jalur URL objek baru akan dikembalikan kepada Anda.

MENGHAPUS:

Digunakan untuk menghapus sumber daya.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

TARUH:

Digunakan untuk membuat sumber daya, atau menimpanya, saat Anda menentukan URL sumber daya.

Untuk sumber daya baru:

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Untuk menimpa sumber daya yang ada:

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

... Ya, mereka sama. PUT sering kali dideskripsikan sebagai metode 'edit', karena dengan mengganti seluruh sumber daya dengan versi yang sedikit diubah, Anda telah mengedit apa yang akan didapatkan klien saat mereka melakukannya nanti.

Menggunakan REST dalam bentuk HTML:

Spesifikasi HTML5 mendefinisikan GET dan POST untuk elemen formulir .

Atribut konten metode adalah atribut yang disebutkan dengan kata kunci dan status berikut:

  • Kata kunci GET, pemetaan ke status GET, menunjukkan metode HTTP GET.
  • Kata kunci POST, pemetaan ke status POST, menunjukkan metode HTTP POST.

Secara teknis, spesifikasi HTTP tidak membatasi Anda hanya pada metode tersebut. Secara teknis Anda bebas menambahkan metode apa pun yang Anda inginkan, namun dalam praktiknya, ini bukan ide yang bagus. Idenya adalah bahwa semua orang tahu bahwa Anda menggunakan GET untuk membaca data, jadi akan membingungkan jika Anda memutuskan untuk menggunakan BACA. Yang mengatakan ...

PATCH:

Ini adalah metode yang didefinisikan dalam RFC formal. Ini dirancang untuk digunakan ketika Anda ingin mengirim hanya sebagian modifikasi ke sumber daya, itu akan digunakan seperti PUT:

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Perbedaannya adalah PUT harus mengirim seluruh sumber daya, tidak peduli seberapa besar itu dibandingkan dengan apa yang sebenarnya berubah, sementara PATCH Anda hanya dapat mengirim perubahan.

— Brian R. Bondy
sumber
Hai Brian .. semakin banyak saya membaca ini, semakin masuk akal. Saya berasumsi bahwa beberapa browser (atau versi browser) tidak mendukung PUT atau DELETE? jika demikian, apakah kita menggunakan POST?
— Pure.Krome
1
Hai Pure.Knome; Browser web mendukung semuanya, juga perpustakaan HTTP apa pun harus mendukung semuanya juga.
— Brian R. Bondy
4
Saya akan merekomendasikan membeli buku ini jika Anda ingin mempelajari semua tentang REST oreilly.com/catalog/9780596529260
— Brian R. Bondy
1
@ Brian: beberapa pertanyaan lagi tentang contoh PUT Anda. >> PUT / pertanyaan / <new_question> Mengapa Anda melakukan itu, daripada melakukan >> PUT / pertanyaan / karena semua data di formulir akan digunakan untuk membuat sumber daya baru? (lanjutan komentar selanjutnya) ...
— Pure.Krome
1
@ Brian R. Bondy, Terima kasih atas jawaban Anda yang luar biasa. Permintaan POST ke sumber daya yang ada dideskripsikan sebagai "menambahkan" dalam buku tenang oreilly (hal: 100,101), bertentangan dengan istilah "modifikasi" umum Anda. Lagi pula, menambahkan lebih spesifik daripada memodifikasi - yang dapat menyampaikan "PUT ke sumber daya yang ada" - dan secara semantik terdengar lebih tepat untuk POST - menambahkan sumber daya baru ke tautan yang ditentukan, baik dengan menambahkan atau membuat sumber daya turunan ke sana .
— Özgür
11

Dengan asumsi /questions/10pertanyaan yang valid maka metode yang digunakan untuk berinteraksi dengannya.

POSTING untuk menambahkannya

PUT untuk membuat atau menggantinya

DAPATKAN untuk melihat / menanyakannya

dan HAPUS dengan baik .. hapus itu.

Url tidak berubah.

— Allain Lalonde
sumber
4
Salah. PUT harus idempoten. Anda harus dapat membuat permintaan PUT yang sama berkali-kali, tanpa efek setelah pertama kali. Jadi, membuat sumber daya dengan setiap permintaan PUT bukanlah idempoten.
— aehlke
3
"Metode PUT dan DELETE didefinisikan sebagai idempoten, yang berarti bahwa beberapa permintaan yang identik harus memiliki efek yang sama seperti permintaan tunggal.", Menggunakan put pada URI yang saat ini tidak menyediakan Sumber Daya dapat membuat sumber daya. PUTting lagi segera hanya akan melakukannya lagi yang tidak akan berpengaruh. Dengan cara ini Anda membuat sumber daya, tetapi kueri masih idempoten. Jika nanti Anda kembali dan ingin mengubah sumber daya, Anda mengatur PUT ke URI yang sama dengan data yang berbeda (yang akan menjadi permintaan yang berbeda dan dengan sendirinya dapat diulang beberapa kali dengan hasil yang sama).
— Allain Lalonde
1
Sebenarnya coba lihat jawaban yang mendapat 25 suara di atas disebutkan bahwa PUT bisa digunakan untuk membuat atau mengganti resource.
— Allain Lalonde
3
Pembuatan hanya berfungsi selama menentukan ID sumber daya baru diperbolehkan. Meskipun dimungkinkan, lebih sering lebih meyakinkan bagi pengguna untuk POST ke / collection dan mengembalikan tautan yang menyertakan id baru:
— pgraham
2
@aehIke Pembuatan sumber daya baru oleh PUT tidak menjadikannya non-idempoten karena idenya adalah jika saya 'PUT / items / 10' dan item 10 tidak ada sebelumnya, maka itu hanya akan dibuat. Namun jika saya 'PUT / items / 10' lagi untuk kedua kalinya, nah sekarang sudah ada jadi hanya akan diganti maka idempotensi dipertahankan karena permintaan PUT berikutnya tidak memiliki efek samping baru. (Tentu saja itu dengan asumsi bahwa saya terus meletakkan barang yang persis sama setiap kali)
— Alappin
3

Saya akan mengambil risiko dan menebak bahwa yang Anda maksud adalah pengontrol standar untuk MVC saat Anda mengucapkan url "RESTful", karena contoh Anda dapat dianggap non- "RESTful" (lihat ini artikel ).

Karena Rails benar-benar mempopulerkan gaya URL yang tampaknya Anda minati, saya menawarkan di bawah ini tindakan pengontrol default yang dihasilkan oleh ScaffoldingGenerator di Ruby on Rails. Ini seharusnya sudah familiar bagi siapa saja yang menggunakan aplikasi Rails.

Tindakan dan tampilan perancah adalah: indeks, daftar, tampilkan, baru, buat, edit, perbarui, hancurkan

Biasanya Anda akan membuat ini sebagai:

http://application.com/controller/<action>/<id>
— tvanfosson.dll
sumber
5
Konvensi URI out-of-band TIDAK RESTful. Mengutip Fielding sendiri: "REST API tidak boleh menentukan nama resource tetap atau hierarki (penggabungan klien dan server yang jelas). Server harus memiliki kebebasan untuk mengontrol namespace mereka sendiri. Sebagai gantinya, izinkan server untuk menginstruksikan klien tentang cara membuat URI yang sesuai , seperti yang dilakukan dalam bentuk HTML dan template URI, dengan mendefinisikan instruksi tersebut dalam jenis media dan hubungan tautan .. "
— aehlke
1

Berikut adalah pemetaan URL Anda saat ini menggunakan prinsip REST:

/question/show/<whatever>

Jika Anda mengidentifikasi pertanyaan sebagai sumber daya, maka pertanyaan tersebut harus memiliki URL yang unik. Menggunakan GET untuk menampilkannya (mengambilnya) adalah praktik umum. Menjadi:

GET /question/<whatever>

/question/edit/<whatever>

Sekarang Anda ingin pengguna memiliki tampilan lain dari sumber daya yang sama yang memungkinkannya untuk mengedit sumber daya (mungkin dengan kontrol formulir).

Dua opsi di sini, aplikasi Anda adalah aplikasi (bukan situs web), maka Anda mungkin lebih baik menggunakan JavaScript untuk mengubah sumber daya menjadi sumber daya yang dapat diedit di sisi klien.

Jika ini adalah situs web, Anda dapat menggunakan URL yang sama dengan informasi tambahan untuk menentukan tampilan lain, praktik yang umum adalah:

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

Ini untuk mengubah pertanyaan, jadi PUT adalah metode yang benar untuk digunakan:

PUT /question/<whatever>

/question/list   (lists the questions)

Daftar pertanyaan sebenarnya adalah sumber induk dari sebuah pertanyaan, jadi secara alami adalah:

GET /question

Sekarang Anda mungkin membutuhkan lebih banyak lagi:

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

Tada :)

— Vincent Robert
sumber
-1

Empat contoh Anda bisa jadi:

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

Untuk menambahkan pertanyaan:

POST /questions q=What+is+the+meaning+of+life

Server akan merespon:

200 OK (or 201 Created)
Location: /questions/456
— pbreitenbach.dll
sumber
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.