REST API - mengapa menggunakan PUT DELETE POST GET?

Jadi, saya melihat-lihat beberapa artikel tentang cara membuat REST API. Dan beberapa dari mereka menyarankan menggunakan semua jenis permintaan HTTP: suka PUT DELETE POST GET. Kami akan membuat misalnya index.php dan menulis API dengan cara ini:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

OK, memang - saya belum tahu banyak tentang layanan web (belum). Tapi, bukankah akan lebih mudah untuk hanya menerima objek JSON melalui reguler POSTatau GET(yang akan berisi nama metode dan semua parameter) dan kemudian merespons dalam JSON juga. Kita dapat dengan mudah membuat serial / deserialize melalui PHP json_encode()dan json_decode()dan melakukan apa pun yang kita inginkan dengan data itu tanpa harus berurusan dengan metode permintaan HTTP yang berbeda.

Apakah saya melewatkan sesuatu?

PEMBARUAN 1:

Ok - setelah menggali berbagai API dan belajar banyak tentang XML-RPC , JSON-RPC , SOAP , REST Saya sampai pada kesimpulan bahwa jenis API ini masuk akal. Sebenarnya pertukaran stack cukup banyak menggunakan pendekatan ini di situs mereka dan saya pikir orang-orang ini tahu apa yang mereka lakukan Stack Exchange API .

Gagasan RE Presentational S tate T ransfer bukan tentang mengakses data dengan cara sesederhana mungkin.

Anda menyarankan menggunakan permintaan pos untuk mengakses JSON, yang merupakan cara yang sah untuk mengakses / memanipulasi data.

REST adalah metodologi untuk akses data yang bermakna . Ketika Anda melihat permintaan di REST, itu harus segera menilai apa yang terjadi dengan data.

Sebagai contoh:

GET: /cars/make/chevrolet

kemungkinan akan mengembalikan daftar mobil chevy. Api REST yang baik bahkan mungkin memasukkan beberapa opsi keluaran di querystring seperti ?output=jsonatau ?output=htmlyang akan memungkinkan accessor untuk memutuskan format informasi yang harus dikodekan.

Setelah sedikit berpikir tentang cara memasukkan data yang masuk ke dalam REST API, saya menyimpulkan bahwa cara terbaik untuk menentukan tipe data secara eksplisit adalah melalui ekstensi file yang sudah ada seperti .js,.json , .html, atau .xml. Ekstensi file yang hilang akan default ke format apa pun yang default (seperti JSON); ekstensi file yang tidak didukung dapat mengembalikan 501 Not Implementedkode status .

Contoh lain:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

kemungkinan akan membuat malibu chevy baru di db dengan warna terkait. Saya katakan kemungkinan karena api REST tidak perlu berhubungan langsung dengan struktur database. Ini hanya antarmuka masking sehingga data yang sebenarnya dilindungi (anggap saja seperti accessors dan mutators untuk struktur database).

Sekarang kita perlu beralih ke masalah idempotensi . Biasanya REST mengimplementasikan CRUD melalui HTTP. HTTP menggunakan GET, PUT, POSTdan DELETEuntuk permintaan.

Implementasi REST yang sangat sederhana dapat menggunakan pemetaan CRUD berikut:

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

Ada masalah dengan implementasi ini: Posting didefinisikan sebagai metode non-idempoten. Ini berarti bahwa panggilan selanjutnya dari metode Post yang sama akan menghasilkan status server yang berbeda . Dapatkan, Pasang, dan Hapus, idempoten; yang berarti bahwa memanggil mereka beberapa kali akan menghasilkan keadaan server yang identik.

Ini berarti permintaan seperti:

Delete: /cars/oldest

sebenarnya bisa diimplementasikan sebagai:

Post: /cars/oldest?action=delete

Sedangkan

Delete: /cars/id/123456

akan menghasilkan status server yang sama jika Anda memanggilnya sekali, atau jika Anda memanggilnya 1000 kali.

Cara yang lebih baik untuk menangani penghapusan oldestitem adalah dengan meminta:

Get: /cars/oldest

dan gunakan IDdari data yang dihasilkan untuk membuat deletepermintaan:

Delete: /cars/id/[oldest id]

Masalah dengan metode ini adalah jika /carsitem lain ditambahkan antara saat /oldestdiminta dan ketika deletedikeluarkan.

Ini adalah pertanyaan keamanan dan pemeliharaan.

metode yang aman

Jika memungkinkan, Anda harus menggunakan metode 'aman' (searah) seperti GET dan HEAD untuk membatasi potensi kerentanan.

metode idempoten

Kapan pun memungkinkan, Anda harus menggunakan metode 'idempoten' seperti GET, HEAD, PUT dan DELETE, yang tidak dapat memiliki efek samping dan karena itu lebih rentan kesalahan / mudah dikendalikan.

Sumber

Singkatnya, REST menekankan kata benda di atas kata kerja. Ketika API Anda menjadi lebih kompleks, Anda menambahkan lebih banyak hal, daripada lebih banyak perintah.

Anda bertanya :

bukankah akan lebih mudah untuk hanya menerima objek JSON melalui $ _POST normal dan kemudian merespons dalam JSON juga

Dari Wikipedia di REST :

Aplikasi RESTful memaksimalkan penggunaan antarmuka yang sudah ada, didefinisikan dengan baik dan kemampuan built-in lainnya yang disediakan oleh protokol jaringan yang dipilih, dan meminimalkan penambahan fitur khusus aplikasi baru di atasnya.

Dari apa (kecil) yang pernah saya lihat, saya percaya ini biasanya dicapai dengan memaksimalkan penggunaan kata kerja HTTP yang ada, dan merancang skema URL untuk layanan Anda yang sekuat dan jelas mungkin.

Protokol data khusus (meskipun dibangun di atas yang standar, seperti SOAP atau JSON) tidak disarankan, dan harus diminimalkan agar sesuai dengan ideologi REST.

SOAP RPC melalui HTTP, di sisi lain, mendorong setiap perancang aplikasi untuk mendefinisikan kosakata kata benda dan kata kerja yang baru dan sewenang-wenang (misalnya getUsers (), savePurchaseOrder (...)), biasanya dilapiskan ke kata kerja 'POST' HTTP. Ini mengabaikan banyak kemampuan HTTP yang ada seperti otentikasi, caching, dan negosiasi jenis konten, dan dapat membuat perancang aplikasi menciptakan kembali banyak fitur ini di dalam kosa kata baru.

Objek aktual yang Anda kerjakan dapat dalam format apa pun. Idenya adalah untuk menggunakan kembali HTTP sebanyak mungkin untuk mengekspos operasi Anda yang ingin dilakukan pengguna pada sumber daya tersebut (kueri, manajemen negara / mutasi, penghapusan).

Anda bertanya :

Apakah saya melewatkan sesuatu?

Ada banyak lagi yang perlu diketahui tentang REST dan sintaksis URI / HTTP itu sendiri. Sebagai contoh, beberapa kata kerja idempoten, yang lain tidak. Saya tidak melihat apa-apa tentang ini dalam pertanyaan Anda, jadi saya tidak repot-repot mencoba menyelami itu. Jawaban lain dan Wikipedia sama-sama memiliki banyak informasi bagus.

Juga, ada banyak hal untuk dipelajari tentang berbagai teknologi jaringan yang dibangun di atas HTTP yang dapat Anda manfaatkan jika Anda menggunakan API yang benar-benar tenang. Saya akan mulai dengan otentikasi.

Dalam hal menggunakan ekstensi untuk menentukan tipe data. Saya perhatikan bahwa API MailChimp melakukannya, tapi saya rasa ini bukan ide yang baik.

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

Suara saya seperti ide yang bagus, tapi saya pikir pendekatan "lebih tua" lebih baik - menggunakan header HTTP

GET /xxx/cars/1
Accept: application/json

Header HTTP juga jauh lebih baik untuk komunikasi tipe data silang (jika seseorang membutuhkannya)

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  

Apakah saya melewatkan sesuatu?

Iya. ;-)

Fenomena ini ada karena kendala antarmuka yang seragam . REST suka menggunakan standar yang sudah ada alih-alih menciptakan kembali roda. Standar HTTP telah terbukti sangat terukur (web berfungsi untuk sementara waktu). Kenapa kita harus memperbaiki sesuatu yang tidak rusak ?!

Catatan: Kendala antarmuka seragam adalah penting jika Anda ingin memisahkan klien dari layanan. Ini mirip dengan mendefinisikan antarmuka untuk kelas untuk memisahkan mereka dari satu sama lain. Ofc. di sini antarmuka yang seragam terdiri dari standar seperti HTTP , tipe MIME , URI , RDF , vocab data tertaut , hydra vocab , dll ...

Semantik yang baik penting dalam pemrograman.

Memanfaatkan lebih banyak metode selain GET / POST akan membantu karena akan meningkatkan keterbacaan kode Anda dan membuatnya lebih mudah untuk dipelihara.

Mengapa?

Karena Anda tahu GET akan mengambil data dari api Anda. Anda tahu POST akan menambahkan data baru ke sistem Anda. Anda tahu PUT akan membuat pembaruan. HAPUS akan menghapus baris dll, dll,

Saya biasanya menyusun Layanan Web RESTFUL saya sehingga saya memiliki fungsi panggil balik bernama hal yang sama dengan metode.

Saya menggunakan PHP, jadi saya menggunakan function_exists (saya pikir itu namanya). Jika fungsi tidak ada, saya melempar 405 (METODE TIDAK DIIZINKAN).

Bill Venners: Dalam posting blog Anda yang berjudul "Mengapa REST Gagal," Anda mengatakan bahwa kami membutuhkan keempat kata kerja HTTP — GET, POST, PUT, dan DELETE — dan menyesalkan bahwa vendor browser hanya GET dan POST. "Mengapa kita membutuhkan keempatnya? kata kerja? Mengapa GET dan POST tidak cukup?

Elliotte Rusty Harold: Ada empat metode dasar dalam HTTP: GET, POST, PUT, dan DELETE. GET digunakan sebagian besar waktu. Ini digunakan untuk apa pun yang aman, yang tidak menimbulkan efek samping. GET dapat di-bookmark, di-cache, ditautkan, dilewatkan melalui server proxy. Ini adalah operasi yang sangat kuat, operasi yang sangat berguna.

Sebaliknya POST mungkin adalah operasi yang paling kuat. Itu bisa melakukan apa saja. Tidak ada batasan untuk apa yang bisa terjadi, dan akibatnya, Anda harus sangat berhati-hati dengannya. Anda tidak membookmarknya. Anda tidak menyimpannya. Anda tidak mengambilnya sebelumnya. Anda tidak melakukan apa pun dengan POST tanpa meminta pengguna. Apakah Anda ingin melakukan ini? Jika pengguna menekan tombol, Anda dapat POST beberapa konten. Tetapi Anda tidak akan melihat semua tombol pada halaman, dan mulai menekannya secara acak. Sebaliknya, browser mungkin melihat semua tautan pada halaman dan mengambilnya sebelumnya, atau mengambilnya terlebih dahulu, yang menurut mereka paling mungkin diikuti selanjutnya. Dan pada kenyataannya beberapa browser dan ekstensi Firefox dan berbagai alat lain telah mencoba melakukan itu pada satu titik atau yang lain.

PUT dan DELETE berada di antara GET dan POST. Perbedaan antara PUT atau DELETE dan POST adalah bahwa PUT dan DELETE adalah * idempoten, sedangkan POST tidak. PUT dan DELETE dapat diulang jika perlu. Katakanlah Anda mencoba mengunggah halaman baru ke situs. Katakanlah Anda ingin membuat halaman baru di http://www.example.com/foo.html, jadi Anda mengetik konten Anda dan Anda Taruh di URL itu. Server membuat halaman itu di URL yang Anda berikan. Sekarang, anggaplah karena suatu alasan koneksi jaringan Anda turun. Anda tidak yakin, apakah permintaannya berhasil atau tidak? Mungkin jaringannya lambat. Mungkin ada masalah server proxy. Jadi tidak apa-apa untuk mencobanya lagi, atau lagi — sebanyak yang Anda suka. Karena MENEMPATKAN dokumen yang sama ke URL yang sama sepuluh kali tidak akan ada bedanya dengan meletakkannya sekali. Hal yang sama berlaku untuk DELETE. Anda dapat HAPUS sesuatu sepuluh kali, dan itu sama dengan menghapusnya sekali.

Sebaliknya, POST, dapat menyebabkan sesuatu yang berbeda terjadi setiap kali. Bayangkan Anda keluar dari toko online dengan menekan tombol beli. Jika Anda mengirim permintaan POST itu lagi, Anda bisa membeli semuanya di keranjang Anda untuk kedua kalinya. Jika Anda mengirimnya lagi, Anda telah membelinya untuk ketiga kalinya. Itu sebabnya browser harus sangat berhati-hati dalam mengulangi operasi POST tanpa persetujuan pengguna eksplisit, karena POST dapat menyebabkan dua hal terjadi jika Anda melakukannya dua kali, tiga hal jika Anda melakukannya tiga kali. Dengan PUT dan DELETE, ada perbedaan besar antara nol permintaan dan satu, tetapi tidak ada perbedaan antara satu permintaan dan sepuluh permintaan.

Silakan kunjungi url untuk lebih jelasnya. http://www.artima.com/lejava/articles/why_put_and_delete.html

Memperbarui:

Metode idempoten HTTP idempoten adalah metode HTTP yang dapat dipanggil berkali-kali tanpa hasil yang berbeda. Tidak masalah jika metode ini dipanggil hanya sekali, atau sepuluh kali lipat. Hasilnya harus sama. Sekali lagi, ini hanya berlaku untuk hasilnya, bukan sumber daya itu sendiri. Ini masih dapat dimanipulasi (seperti cap waktu pembaruan, asalkan informasi ini tidak dibagikan dalam representasi sumber daya (saat ini).

Perhatikan contoh-contoh berikut:

a = 4;

a ++;

Contoh pertama adalah idempoten: tidak peduli berapa kali kita menjalankan pernyataan ini, a akan selalu 4. Contoh kedua bukan idempoten. Menjalankan ini 10 kali akan menghasilkan hasil yang berbeda seperti ketika menjalankan 5 kali. Karena kedua contoh mengubah nilai a, keduanya adalah metode yang tidak aman.

Pada dasarnya REST adalah ( wiki ):

1. Arsitektur client-server
2. Kewarganegaraan
3. Cacheability
4. Sistem berlapis
5. Kode sesuai permintaan (opsional)
6. Antarmuka yang seragam

REST bukan protokol, itu prinsip. Uris dan metode berbeda - seseorang yang disebut praktik terbaik.