Sayangnya, Connection sudah memiliki pengakses options sehingga kami tidak dapat menggunakannya kembali untuk membuat permintaan OPTIONS. Anda harus menggunakan run_request(:options)

Mungkin itu asumsi yang naif tetapi bukankah lebih mudah untuk memetakan kembali :options ke, saya tidak tahu, :configuration , daripada memiliki pola penggunaan yang berbeda?

Saya tidak ingin mengubah API yang sudah ada untuk mendukung HTTP yang jarang digunakan
metode yang mudah diakses melalui run_request .

IMHO, keputusan ini harus dipertimbangkan kembali. OPTIONS adalah nama metode HTTP yang valid dan run_request tidak selalu merupakan alternatif yang sesuai. Jika kita akan merusak API publik, lebih baik melakukannya sekarang, sebelum kita merilis 1.0, daripada menyesali keputusannya nanti.

Mengapa run_request tidak selalu merupakan alternatif yang cocok?

Untuk penulis perpustakaan tingkat rendah yang membangun di atas Faraday, saya akan
sebenarnya merekomendasikan menggunakan run_request lebih dari get , post metode.

@mislav #run_request tidak mengambil blok, seperti #get , #post , dll. Lihatlah bagaimana saya menggunakan Faraday di Twitter::REST::Client#request : https://github.com/sferik/twitter/blob/master/lib/twitter/rest/client.rb#L130 -L144

run_request tidak mengambil blok, seperti #get, #post, dll.

Apa yang membuatmu berpikir begitu ?

Kasus penggunaan Anda adalah contoh sempurna saat menggunakan run_request , yaitu untuk menghindari send .

Sekarang saya ingat mengapa saya tidak suka #run_request . Saya sebenarnya menggunakannya pada satu titik dalam kode Twitter::Client#request tetapi menghapusnya sebagai bagian dari refactoring: https://github.com/sferik/Twitter/commit/2d70b64674bdc204c85c47327afa571f9641e545. Saya pikir Anda harus mengakui, kode ini jauh lebih bersih dengan #send (saya berharap ini tidak terjadi).

Dengan #run_request , saya harus khawatir tentang apakah permintaan itu PUT atau POST dan mengatur badan permintaan vs. params kueri untuk GET , DELETE , dll. Dengan metode kata kerja, saya cukup memberikan hash kepada mereka dan mereka tahu cara menanganinya dengan benar. IMHO, ini adalah antarmuka yang jauh lebih ramah daripada dengan #run_request .

Saya menantang Anda untuk mengirimkan permintaan tarik ke permata twitter yang menggantikan #send dengan #run_request yang menghasilkan kode yang tidak terlalu rumit (menurut Code Climate atau analisis statis lainnya ).

Untuk mempertahankan metode OPTIONS , sangat sulit untuk menebak popularitas kata kerja HTTP di masa depan. Di HTTP 1.0, hanya ada GET dan POST. Pada tahun 1999, lebih banyak kata kerja ditambahkan di HTTP 1.1, tetapi kebanyakan diabaikan sampai Rails 2 menambahkan dukungan untuk PUT dan DELETE di rute sumber daya. Sekarang, di Rails 4, PATCH didukung bersama PUT . Beberapa tahun yang lalu, Anda mungkin (dengan benar) mengklaim bahwa " PATCH tidak terlalu populer" dan oleh karena itu tidak memerlukan dukungan kelas satu. Hari ini, semua server API baru yang ditulis dalam Rails mendukung PATCH , termasuk GitHub API , yang mendukung PATCH sebelum Rails 4 dirilis. GitHub API juga mendukung OPTIONS untuk Cross Origin Resource Sharing (CORS). Penggunaan OPTIONS mungkin belum populer tetapi akan menjadi populer hampir dalam semalam jika CORS ditambahkan sebagai default di Rails 5. Jika ini terjadi, saya pikir Anda akan menyesal mengabaikan masalah ini.

Kata kerja HTTP adalah kata cadangan penting untuk pustaka HTTP. Hanya ada beberapa dari mereka dan menurut saya, kita harus mendukung mereka semua sebagai warga negara kelas satu di Faraday 1.0, bahkan jika itu berarti merusak segalanya.

CORS adalah kasus penggunaan yang sangat penting. Saya akan kecewa jika 1.0 dikirimkan tanpa OPTIONS sebagai kata kerja kelas satu.

Saya sangat menyesal untuk _bump_ ini, tetapi ada kesepakatan untuk mendukung options sebagai metode untuk permintaan OPTIONS ? Saya akan dengan senang hati mengirimkan permintaan tarik untuk mewujudkannya.

Aku masih belum menjual ide itu. Apa yang akan disebut metode options saat ini?

Metode lain yang kami dukung adalah kata kerja: get, post, put, delete. Ini memudahkan untuk memahami bahwa beberapa tindakan sedang terjadi saat Anda memanggil mereka. options tidak akan menjadi kata kerja dan karena itu saya tidak berpikir itu akan menjadi metode singkatan yang bagus. Jika orang menggunakan OPTIONS satu ton dalam kode sehari-hari dan tidak tahan menggunakan run_request untuk beberapa alasan (saya ingin mendengar alasan itu!) maka saya akan menyarankan memberi nama metode baru http_options untuk menunjukkan bahwa ini adalah metode permintaan HTTP.

Argumen "metode lain adalah kata kerja" seharusnya tidak menjadi masalah. Mereka bukan metode di Faraday karena mereka adalah kata kerja, metode itu ada karena mereka adalah metode HTTP. Hal yang sama harus terjadi untuk options IMO.

Jika ini adalah alasan untuk tidak memiliki options , maka head tidak boleh didefinisikan, karena "head" di HTTP bukan tentang "going", kata kerjanya.

Saya benar-benar khawatir tentang melanggar API dengan options , tetapi ini adalah kejutan besar bahwa itu tidak "didukung". Jauh lebih konsisten jika semua metode HTTP ditangani dengan cara yang sama.

Dan tentang tidak menggunakan run_request , seperti yang ditunjukkan sebelumnya, kode tanpanya jauh lebih bersih.

Itu masih panggilan Anda (jelas :-) ) untuk memutuskan untuk mendukung ini atau tidak, tetapi saya ingin mengubah pikiran Anda tentang itu, dan jika itu tidak akan didukung, itu untuk hal lain selain "_options_ tidak sebuah kata kerja".

+1 @nhocki

Ini mengejutkan saya hari ini. Semua contoh dengan conn.get , conn.post , conn.delete dll. membuat saya percaya bahwa cara yang jelas untuk melakukan permintaan OPSI adalah conn.options .

Mungkin kita dapat mendokumentasikan ketidakkonsistenan ini dan solusi run_request di Faraday::Connection rdocs atau README? Saya senang membuat permintaan tarik.

+1

Mengapa opsi tidak sama dengan GET, POST, DELETE?

Meskipun saya pribadi setuju dengan @mislav , saya tidak bisa mengabaikan pendapat @sferik dan umpan balik komunitas. Saya memeriksa kode dan memperhatikan bahwa options hanyalah sebuah attr_reader , ditambah lagi itu digunakan terutama oleh tes.
Namun, kita berbicara tentang API publik yang berpotensi merusak beberapa implementasi yang sedang diubah, oleh karena itu ini hanya akan dibahas di Faraday 1.0
Sampai saat itu, senang untuk membahas kembali ini jika ada yang menentangnya

Saya pikir conn.options harus benar-benar menjadi sesuatu. Keberadaannya sangat dipengaruhi oleh keberadaan conn.get , conn.post , dll. Tetapi karena akan merusak kompatibilitas ke belakang, v1.0 terdengar seperti target yang bagus untuk dimasukkan ke dalam ini.

Kabar baik, semuanya! Saya menerapkan ini dengan membebani #options untuk mendukung perilaku baru, sambil mempertahankan perilaku yang ada. https://github.com/lostisland/faraday/pull/857