Sebagai orang yang fokus pada frontend yang juga melakukan node.js dari waktu ke waktu, axios telah menjadi tujuan saya.
API Mudah, dari Facebook, berfungsi di browser dan node? Selesai

Per diskusi baru-baru ini dengan @mikeal , saya sudah mencoba Bent. Sebagai pengembang Node.js yang telah menggunakan permintaan untuk sementara waktu sekarang, bent jelas merupakan transisi yang mudah - sangat direkomendasikan

@reconbot Anda mungkin ingin menambahkan got , needle dan urllib .

Yah, rasanya agak salah untuk mempromosikan perpustakaan kecil saya sendiri di sini, tetapi karena itulah tujuan masalahnya, ini dia: request-compose adalah klien HTTP 0 deps yang fungsional dengan dukungan untuk janji, aliran, dan banyak opsi berguna lainnya, yang sebagian besar sangat mirip dengan yang ditemukan dalam permintaan.

Saya juga menulis artikel tentang itu. Ide umumnya adalah bahwa setiap orang didorong untuk membuat klien HTTP mereka sendiri, yang secara khusus disesuaikan dengan kebutuhan mereka sendiri.

Adapun ukuran bundel, saya tidak tahu, tetapi seharusnya cukup kecil, meskipun klien ini tidak pernah dirancang untuk digunakan di browser.

Mungkin baik untuk menambahkan kolom berikut ke tabel:

• Jumlah bintang di Github (ya saya sudah tahu ini bukan satu-satunya faktor saat memilih lib)
• Jumlah unduhan npm (mungkin mingguan, stat yang sama dengan situs web npm, dan ya saya sudah tahu ini bukan satu-satunya faktor saat memilih lib)

Saat menempatkan angka-angka ini berdampingan, beberapa lib memiliki ribuan bintang dan jutaan unduhan setiap minggu, vs yang lain dalam ratusan.

2 sen saya, OK untuk mengabaikan dan melanjutkan, tidak perlu mengoreksi atau membantah komentar.

@csantanapr Saya setuju, mungkin perlu membandingkan set fitur juga. Dukungan proxy, dukungan cache, fitur auth, dll. Jika Anda menggunakan fitur permintaan tertentu dan perlu menemukannya di tempat lain, ini saat yang tepat untuk membicarakannya.

axios mendapatkan suara saya, terutama sebagai front-ender.

Layak untuk dilihat: ky (frontend) dan ky-universal (isomorfik)

Pengguna Axios di sini. Dengan begitu, semua tim kami dapat menggunakan pustaka yang sama terlepas dari lingkungan: browser atau nodejs (berjalan di server atau tanpa server). Sangat terawat dengan baik, dan semua orang kami menyukainya.

Kami memiliki perbandingan yang baik antara got , request , node-fetch , axios , dan superagent di got readme : https://github.com/sindresorhus/got#comparison
(PR selamat datang jika Anda melihat ada ketidakakuratan. Kami telah berusaha membuatnya senetral mungkin)

Got juga memiliki panduan migrasi untuk berpindah dari request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Bagi saya, saya cenderung melakukan pembungkus di sekitar fetch api, jadi pengambilan simpul adalah goto saya. Terlepas dari aspek negatifnya, saya biasanya memuatnya ke global.fetch di node, jadi saya bisa mengandalkannya selalu tersedia, seperti di browser (melalui polyfill untuk browser lama). Dapat juga menggunakan isomorphic-fetch yang merupakan pembungkus sekitar pengambilan simpul untuk simpul, dan pengambilan polyfill (atau pengambilan yang sudah tersedia) di browser. Karena saya tidak harus mendukung browser lawas, saya hanya menggunakan global, dan menetapkan global untuk digunakan di node.js.

Hei, Wreck (https://www.npmjs.com/package/wreck) adalah yang saya gunakan

Saya lebih suka sesuatu yang meniru api pengambilan pada klien. Libs seperti axios, superagent, dll adalah abstraksi tingkat yang lebih tinggi di atas perpustakaan permintaan standar. Sebagai pengganti perpustakaan permintaan tingkat rendah, saya ingin melihat sesuatu yang mencerminkan padanan tingkat rendah pada klien untuk tujuan pengembangan js universal. Lib seperti axios dan superagent kemudian dapat mengimplementasikan kembali dirinya sendiri di atas itu, dan penggunanya dapat terus menggunakannya, tetapi itu tidak boleh dianggap mendasar untuk tujuan ini.

@Velveeta Saya pergi dan melihat basis kode axios dan tidak melihat bukti bahwa itu didasarkan pada "perpustakaan permintaan standar tingkat rendah". Tolong beri tahu saya bagaimana Anda sampai pada kesimpulan ini?

Perbandingan @sindresorhus sejauh ini merupakan pendekatan yang lebih baik daripada daftar saya di atas. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch adalah blok bangunan tingkat rendah yang cocok untuk sebagian besar klien. Saya ingin melihat permintaan berbasis pengambilan shim.

Saya akan membungkus pengambilan dengan API yang lebih bagus setiap hari. Yah, saya rasa itu hanya masalah preferensi, tetapi menyiratkan bahwa fetch API sangat bagus hanya karena itu adalah standar defacto di browser adalah salah. Saya tahu lebih sedikit noise untuk membuatnya isomorfik di kedua sisi, tetapi itu tidak membuatnya lebih baik.

Ada r2 oleh @mikeal sendiri. Ini dimaksudkan untuk menjadi penerus spiritual request . Ini memiliki API Janji dan dikompresi 16kb.

Axios mungkin berfungsi dengan baik di browser, tetapi pengalaman kami dengannya di Node.js tidak demikian. Juga, saya tidak yakin apakah itu dipertahankan secara aktif lagi.

@ kreig303 Saya belum melihat ke internal axios, jadi saya tidak menyadarinya. Sepertinya saat ini didasarkan pada XHR biasa, yang masuk akal, karena ini adalah solusi untuk permintaan klien dan server. Saya hanya bermaksud bahwa axios cukup kaya fitur, dan sesuatu yang sedikit lebih sederhana harus dipertimbangkan untuk modul dasar seperti pengganti permintaan, dan kemudian biarkan lib kaya fitur lainnya dibangun di atas itu jika mereka menginginkannya. Saya memilih sesuatu yang mencerminkan API pengambilan khusus untuk tujuan memiliki API yang konsisten pada klien dan server (seperti XHR yang mendasari aksio), dan karena itu adalah penerus logis dari XHR. Jika diinginkan pembungkus API yang lebih bagus, ada banyak peluang untuk membungkusnya dan merilis pustaka lain dengan API yang optimal itu, tetapi saya mendukung paritas fitur dan API antara klien dan server di mana pun itu bisa dilakukan.

Nah, salah satu masalah yang kami minta adalah terlalu banyak fitur, dan terlalu banyak status terekspos, bahkan yang dianggap internal. Merupakan kutukan dan berkah memiliki begitu banyak fitur. Ini adalah berkah karena itulah mengapa itu sangat populer, dan itu yang pertama. Ini adalah kutukan karena tanpa upaya terus-menerus dalam jumlah besar untuk menjaga basis kode tetap bersih, lugas, dan umumnya menarik untuk dikerjakan, proyek akhirnya mati. Dan itu bahkan bukan masalah permintaan, itu adalah perspektif pengguna sendiri yang selalu ingin meletakkan sesuatu di luar lapisan mereka sendiri, dan malah meletakkannya di bawah selimut di tempat lain.

Yah, saya kira axios memiliki keyakinan yang sama..

Jadi apa yang bisa kita semua lakukan sebagai gantinya, adalah menempatkan setidaknya sejumlah upaya untuk memahami cara kerja roda, dan kemudian mencoba memikirkan setiap tugas individu yang ada, dan melihat roda mana yang paling cocok.

@ofrobots itu sedikit tangkapan layar selektif untuk perpustakaan yang sangat populer digunakan. Ini milikku:

FWIW Saya tidak ingat apakah saya menggunakannya sebagai lib back-end, jadi saya tidak dalam posisi untuk memverifikasi klaim Anda (kecuali jika Anda memiliki kasus penggunaan khusus yang tidak tercakup).

@Velveeta Saya melihat ke mana Anda akan pergi dengan ini, saya hanya tidak tahu apakah meta-libs adalah cara untuk pergi.

Suara saya dari Frontend adalah untuk axios . Kecil, stabil, dan dapat diprediksi.

Saya pribadi menggunakan celaka untuk proyek FE dan BE saya - terutama karena API sangat intuitif.

Pembungkus di sekitar pengambilan - bekerja dengan baik dengan pengambilan simpul juga.

Untuk orang-orang yang mencari axios -seperti pengalaman di atas fetch API, ada gaxios . Itu dibangun oleh pengembang di Google dan saat ini mendukung semua interaksi HTTP dari klien Node.js Google API , jadi tampaknya aman untuk menganggapnya sebagai pertempuran yang diuji dan digunakan secara aktif!

(👋 di @JustinBeckwith)

Hei, Wreck (https://www.npmjs.com/package/wreck) adalah yang saya gunakan

Ini juga merupakan klien http yang mendasari untuk kerangka kerja hapijs. Implementasinya sangat bersih untuk boot.

Ada r2 oleh @mikeal sendiri. Ini dimaksudkan untuk menjadi penerus spiritual request . Ini memiliki API Janji dan dikompresi 16kb.

Perpustakaan itu tidak terawat. Jika Anda menginginkan API serupa, saya akan merekomendasikan ky , yang ~1kb diperkecil dan di-gzip, dan dikelola oleh orang yang sama dengan got .

Axios mungkin berfungsi dengan baik di browser, tetapi pengalaman kami dengannya di Node.js tidak demikian. Juga, saya tidak yakin apakah itu dipertahankan secara aktif lagi.

Saya menggunakan axios di Node dengan sangat puas. Terutama di lambda dan terutama karena kaya fitur namun tidak datang dengan rantai ketergantungan yang gila. @ofrobots apa pengalaman Anda dengannya di Node?

Sebagai orang yang fokus pada frontend yang juga melakukan node js dari waktu ke waktu, aksioma telah menjadi tujuan saya. API Mudah, dari Facebook, berfungsi di browser dan node? Selesai

Saya tidak tahu itu Facebook? Tapi ya, ini adalah perpustakaan goto saya untuk semua akses API.

Kami menggunakan perpustakaan ini tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. Kecil, berfungsi di browser dan di server dan dibangun di atas konsep plug-in. Pustaka dibuat untuk memungkinkan penggunaan beberapa jenis cache kompleks secara simultan.

Apakah ada yang menggunakan typed-rest-client dari Microsoft? Sepertinya paket yang dipelihara dengan baik yang ditulis dalam TypeScript (bagi saya ini merupakan nilai tambah yang besar).

ini harus menyertakan wreck (dari ekosistem hapi )

Saya baru-baru ini menggunakan https://github.com/grantila/fetch-h2 dengan sukses besar

Apakah saat ini ada pengganti drop-in yang kompatibel? Itu terintegrasi ke dalam KOA dan memberi saya masalah aliran

Seperti yang disebutkan di awal masalah, saya telah mengerjakan perpustakaan lain yang sekarang saya lebih suka gunakan yang disebut bent .

Untuk sementara bent belum dirancang untuk bekerja di browser. Karena API sekarang cukup stabil, saya meluangkan waktu untuk menulis versi browser selain fetch . Alih-alih mencoba menjelajahi versi Node.js, versi browser adalah titik masuknya sendiri di package.json.

Jadi, ya, bent memiliki dukungan browser sekarang dan ini cukup bagus:

• nol dependensi atau polyfill (sepenuhnya dibangun di atas fetch dan ArrayBuffer, jadi tidak ada Buffer atau Stream polyfill dan tidak ada deps untuk dibundel)
• ~2K bundel webpack tidak diperkecil atau di-gzip (seseorang harus memberi tahu saya apa ini setelah minifier dan kompresor pilihan mereka).
• Semua pengujian lulus dalam headless chrome, yang memiliki cakupan 100% dalam versi Node.js (masih belum memiliki cara yang bagus untuk melakukan pengujian cakupan browser otomatis)

Ini bagus @mikeal

@csantanapr terima kasih! :)

axios dapat merusak layanan simpul Anda: https://github.com/axios/axios/issues/1804

Bagi saya, kekhawatiran utama adalah:

• Apakah ini berfungsi dengan konfigurasi minimal di lingkungan perusahaan saya? (faktor yang berkontribusi: proxy perusahaan adalah HTTP untuk target HTTP dan HTTPS, tidak semua proxy menangani semua sertifikat dengan benar, dengan cara yang sama, ...)
  
  
  
  • Yang ini secara khusus menghentikan saya untuk mematikan Permintaan setahun atau lebih.
  
  
• Apakah itu mendukung streaming, untuk kasus-kasus di mana saya perlu, katakanlah, unggahan/unduhan file proxy?

Setelah itu, saya tidak peduli seperti apa tampilan antarmuka selama operasi yang paling umum nyaman dilakukan. Saya juga tidak terlalu peduli dengan ukuran, sisi server, meskipun itu penting jika Anda ingin menggunakan kembali perpustakaan yang sama di kedua ujungnya.

EDIT: Yeeeaaaah tidak bisa mengatakan saya menyalahkan Anda di sana.

EDIT 2: Kira saya akan melihat node-libcurl .

@joedski ya, hal-hal proxy tidak didukung secara luas di luar permintaan. Dan TBH, mengingat jumlah pekerjaan yang diperlukan untuk membuatnya bekerja dan untuk mendukungnya, saya tidak terkejut tidak ada yang mau melakukannya, termasuk saya;) Saya sudah melakukannya sekali dan saya tidak langsung melompat untuk menulis itu lagi untuk ditekuk ️

Akhirnya saya mulai menggunakan perpustakaan node-libcurl untuk membuat permintaan dari nodejs. Karena menggunakan pustaka ikal asli, yang sangat matang & teruji selama bertahun-tahun dalam produksi. Ini bekerja dengan sempurna dengan semua jenis proxy, pengalihan, dan memiliki antarmuka janji & aliran.

teeny-request (>1jt unduhan mingguan)

Penggantian drop-in untuk permintaan, tetapi jauh lebih kecil - dan dengan lebih sedikit opsi. Menggunakan node-fetch di bawah tenda. Letakkan di tempat Anda akan menggunakan request .

node-fetch dilaporkan secara tidak benar dan hanya versi "browser" yang dilaporkan (mengalahkan poin dari daftar _Node.js_). Inilah yang tampaknya salah diukur:

• https://unpkg.com/[email protected]/browser.js

Sebaliknya, salah satu dari ini harus diukur:

• https://unpkg.com/[email protected]/lib/index.js
• https://unpkg.com/[email protected]/lib/index.mjs
• https://unpkg.com/[email protected]/lib/index.es.js

Mereka ada di sekitar ~ 40kb

unfetch juga salah dilaporkan:

• Beranda mengatakan bahwa "Penggunaan di Node.JS ditangani oleh isomorphic-unfetch", jadi itu harus melaporkan kombinasi keduanya.
• isomorphic-unfetch menggunakan node-fetch ( code , docs ) untuk Node.js, jadi ukuran yang dilaporkan harus setidaknya dari node-fetch (lihat komentar saya sebelumnya).

Karena hal ini telah banyak diangkat, saya harus mengatakan sedikit tentang pengalaman saya dengan node-fetch .

Pertama-tama, ini adalah pencapaian yang cukup bagus. Jumlah upaya kode dan rekayasa yang telah dilakukan jauh lebih besar daripada yang pernah kami ajukan. fetch sepertinya API kecil dan saya pikir orang menganggap upaya untuk menyediakan API yang kompatibel di Node.js adalah nominal, tetapi sebenarnya tidak.

Akibatnya, basis kodenya sangat besar. Ini adalah dependensi yang cukup besar di Node.js, yang mungkin tidak akan Anda lihat sama sekali di bundel browser, tetapi bukan berarti ukuran dependensi tidak menjadi masalah di Node.js, terutama di lingkungan tanpa server.

node-fetch sangat diperlukan saat pengujian karena melakukan semua pekerjaan untuk sepenuhnya meniru API browser, tetapi jika Anda menggunakannya dalam aplikasi, bahkan aplikasi yang dijalankan di Node.js dan browser, itu terlalu banyak kode dan terlalu banyak tipuan yang tidak sepadan.

IMO, pendekatan yang tepat saat ini untuk perpustakaan yang ingin menjadi klien http di Node.js dan browser adalah dengan menerapkan API seragam dengan implementasi terpisah menggunakan fetch di browser dan require(‘http’) di Node.js. Aplikasi, dan klien http, tidak boleh menargetkan fetch atau require(‘http’) secara langsung dan tidak boleh bergantung pada meniru API ini di kedua sisi. Ini sebenarnya jauh lebih mudah daripada yang Anda kira, seperti yang Anda lihat dalam implementasi bent yang sangat kecil https://github.com/mikeal/bent/tree/master/src

@mikeal Saya mengalami kesulitan mengkuadratkan

Akibatnya, basis kodenya sangat besar. Ini adalah dependensi yang cukup besar di Node.js, yang mungkin tidak akan Anda lihat sama sekali di bundel browser, tetapi bukan berarti ukuran dependensi tidak menjadi masalah di Node.js, terutama di lingkungan tanpa server.

dengan ukuran bundel 0,4 kB yang tercantum di OP, mana yang terkecil dari semua alternatif yang diberikan?

@domenic kompleksitas meniru browser API adalah masalah utama, banyak kode dan tipuan yang tidak perlu ketika mencoba untuk men-debug. Anda punya Blob API , Anda punya banyak pengaturan untuk body , Anda punya hampir 400 baris header marshalling , dan itu bahkan tidak melihat API aktual yang diekspos.

Seperti yang saya katakan, ini mengesankan, tetapi juga hanya satu ton kode yang singkat, cerdas, dan pada akhirnya tidak perlu jika Anda ingin melakukan apa pun kecuali meniru fetch API.

@mikeal Anda bahkan tidak menyebutkan bahwa ada lebih banyak kode yang diperlukan agar pengambilan simpul 100% kompatibel dengan API pengambilan: itu tidak mendukung aliran yang dapat dibaca dan ditulis dari what-wg (sesuatu yang Anda perlukan saat meniru lingkungan seperti Pekerja Cloudflare.

Hmm, saya masih tidak begitu mengerti bagaimana mengkuadratkan "satu ton" kode "pada akhirnya tidak perlu" dengan "0,4 kB, kurang dari setiap entri lain di atas meja dan 0,25x ukuran bengkok " (yang seharusnya "benar pendekatan" dan "sangat kecil").

@domenic apakah Anda membandingkan ukuran bundel browser? Saya berbicara tentang kerumitan men-debug ini di Node.js. Di browser saya berharap sebagian besar kode node-fetch tidak ada, jadi saya tidak begitu mengerti apa yang Anda bandingkan.

Saya membandingkan nilai di OP; Saya tidak yakin bagaimana itu diukur. Mungkin itu tidak diukur dengan benar, yang merupakan informasi bagus untuk memperbarui OP!

@domenic ah ya, itu semua adalah ukuran bundel browser, dan karena posnya cukup lama, banyak dari mereka mungkin sudah ketinggalan zaman meskipun angka bent masih cukup dekat.

@root/request - pengganti drop-in 80/20 yang ditulis dalam 500 LoC, dan dependensi NOL:

Dibuat dan diuji terhadap perilaku request.js, dengan sengaja.

https://git.rootprojects.org/root/request.js

Halo semuanya! Saya melakukan sedikit riset untuk menemukan pengganti permintaan yang layak untuk proyek saya. Untuk saat ini, inilah yang saya kumpulkan: https://github.com/emanuelcasco/http-packages-benchmark

Rekomendasi dan pendapat tentu saja diterima!

s request sekarang secara resmi tidak digunakan lagi, saya tidak bisa lebih menekankan pentingnya secara resmi mengusulkan postman-request sebagai pengganti drop-in lengkap fitur untuk request , dan mungkin @root/request untuk mereka yang hanya membutuhkan subset terbatas request dan tidak peduli tentang mis. sungai.

Ini memungkinkan pengelola paket mana pun untuk menghapus request dan menyingkirkan pesan penghentian yang mengganggu tanpa menghabiskan lebih dari beberapa menit waktu pengembangan untuk masalah ini, dan tanpa harus memfaktorkan ulang seluruh pustaka atau aplikasi mereka. Butuh beberapa waktu & frustrasi bagi saya untuk mengetahui bahwa pengganti drop-in seperti itu ada.

Dan ya, saya sadar bahwa "penolakan" saja tidak merusak apa pun. Ya, secara teknis semua orang masih dapat menggunakan request dan mungkin terus menggunakannya bahkan mungkin beberapa dekade yang akan datang. Bukan itu yang seharusnya digunakan untuk penghentian. Penghentian seharusnya bertindak sebagai ajakan untuk bertindak, sebagai "masa tenggang" bagi orang-orang untuk meningkatkan kode mereka sampai seseorang di suatu tempat memutuskan untuk menghentikannya.

Saya benar-benar benci ketika "penghentian" hanya digunakan untuk menandai "akhir dukungan" atau "akhir pemeliharaan", seperti yang terjadi di sini. Tetapi saya tidak akan terlalu repot membeli ini, jika ada pengganti drop-in lengkap fitur yang didukung secara resmi DAN dipelihara secara aktif seperti postman-request .

Sebenarnya, apakah ada yang mempertimbangkan untuk menyerahkan pemeliharaan paket ini kepada tim Tukang Pos? Alih-alih menghentikan request , mengapa tidak mengusulkan agar mereka mem-port postman-request ke request dan membiarkan mereka menjadi pengelola resmi yang baru?

Maaf untuk mempromosikan perpustakaan kecil saya sendiri di sini

Dirancang untuk digunakan hanya di nodejs

const http = require('@zhangfuxing/http');
const assert = require('assert');

(async () => {
  // http
  const httpRes = await http.get('http://baidu.com');
  assert(httpRes.includes('<html>'));

  // https
  const httpsRes = await http.get('https://cnodejs.org/api/v1/topics?limit=1&mdrender=false');
  assert(httpsRes.success === true);

  // download file: use pipe
  const fs = require('fs');
  const res = await http.get('http://localhost:3000', {
    responseType: "stream"
  })
  res.pipe(require('fs').createWriteStream('zfx.txt'))
  // or use pipeline
  const stream = require('stream');
  const util = require('util');
  const pipeline = util.promisify(stream.pipeline);
  const res = await http.get(`${url}/stream`, {
    responseType: "stream"
  });
  await pipeline(res, fs.createWriteStream('zfx.txt'));

  // post Buffer
  const res = await http.post('http://localhost/upload', Buffer.from('abc'));
  assert(res.success === true);

  // post Stream
  const fs = require('fs');
  const readStream = fs.createReadStream('./index.js');
  const res = await http.post('http://localhost/upload', readStream);
  assert(res.success === true);

  // post json
  const data = {
    username: 'zfx',
    password: 'password'
  };
  const res = await http.post('http://localhost/upload', data);
  assert(res.success === true);

  // post application/x-www-form-urlencoded
  const data = {
    username: 'zfx',
    password: 'password'
  };
  const options = {
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    }
  };
  const res = await http.post('http://localhost/upload', data, options);
  assert(res.success === true);

  // post FormData
  const FormData = require('form-data');
  const form = new FormData();
  const fs = require('fs');
  const readStream = fs.createReadStream('./index.js');
  form.append('my_field', 'my value');
  form.append('my_buffer', Buffer.from('abc'));
  form.append('my_file', readStream);
  // Set filename by providing a string for options
  form.append('my_file', readStream, '1.js' );
  // provide an object.
  form.append('my_file', readStream, { 
    filename: 'bar.jpg', 
    contentType: 'image/jpeg', 
    knownLength: 19806
  });
  const formHeaders = form.getHeaders();
  const res = await http.post('http://localhost/upload', form, {
    headers: {
      ...formHeaders,
    },
  });
  assert(res.success === true);

  // head
  const res = await http.head(url);
  assert(res.statusCode === 200);
  assert(res.statusMessage === 'OK');
  assert(res.headers && typeof res.headers === 'object');
  assert(res.statusCode === 200);
  assert(res.data === '');

  // options
  const res = await http.options(url);
  assert(res === 'GET,HEAD,POST,PUT,PATCH,DELETE'); 
})().catch(console.error);

Saya telah menemukan Wretch sebagai pilihan terbaik jika Anda sedang membangun SPA TypeScript modern, mengingat awalnya ditulis dalam TS. Secara efektif fitur sama dengan Axios dan mendukung middleware tambahan . Saya pikir API sedikit lebih baik di beberapa tempat dibandingkan dengan Ky juga.

Adakah dari ini yang mendukung http2?

@sakalys got memiliki dukungan HTTP2 eksperimental, yang akan terpasang dan stabil di rilis besar berikutnya (segera keluar).

hampir drop dalam penggantian?

https://github.com/googleapis/teeny-request

Sangat sedih melihat perpustakaan ini ditinggalkan. Saya suka aksioma, tetapi untuk tujuan tertentu, permintaan adalah pilihan pertama saya.

Salah satu dari waktu permintaan dukungan ini? Seperti waktu untuk byte pertama, kelambatan jaringan dan sebagainya?
Saya menggunakan perpustakaan permintaan untuk sebuah proyek dan waktu sangat penting untuk itu.

Google menawarkan gaxios https://github.com/googleapis/gaxios - axios api over node-fetch

Kami memiliki perbandingan yang baik antara got , request , node-fetch , axios , dan superagent di got readme : https://github.com/sindresorhus/got#comparison
_(PR selamat datang jika Anda melihat ketidakakuratan. Kami telah berusaha untuk membuatnya senetral mungkin)_

Got juga memiliki panduan migrasi untuk berpindah dari request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Dapatkan panduan migrasi untuk berpindah dari request telah _pindah_ ke:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

Bolehkah saya menyarankan menambahkan permintaan tukang pos? Saya akan mencoba yang ini di proyek saya berikutnya. Bagaimanapun, inilah yang dikatakan tentangnya di dokumentasi ...

Ini adalah cabang dari modul permintaan yang sangat baik, yang digunakan di dalam Postman Runtime. Ini berisi beberapa perbaikan bug yang tidak diperbaiki dalam permintaan.

Redaxios seperti 800 byte menggunakan pengambilan asli https://github.com/developit/redaxios

Astaga!! Saya mencari tahu ini dari 3 jam memeriksa kode saya lagi dan lagi. Dan itu memberi saya kesalahan 404, saya frustrasi. Terima kasih banyak. Saya pikir saya akan pergi dengan Fetch.

https://www.npmjs.com/package/teeny-request adalah opsi lain, yang digunakan oleh Google API.

Seperti permintaan, tetapi jauh lebih kecil - dan dengan lebih sedikit opsi. Menggunakan pengambilan simpul di bawah tenda. Letakkan di tempat Anda akan menggunakan permintaan. Meningkatkan waktu pemuatan dan penguraian modul.

Apa yang lebih baik node-fetch atau versi bercabang dari requests yang sekarang dikelola oleh PostMan. Saya baru saja memulai perjalanan Node saya, jadi saya membutuhkan sesuatu yang sederhana.

batas waktu axios sepertinya tidak pernah diperbaiki👎🏿

Saya sangat terkejut tidak melihat phin di sini.

https://github.com/ethanent/phin

Bagaimana dengan url-request ?

https://github.com/Debdut/Url

Bagaimana dengan url-request ?

https://github.com/Debdut/Url

Masih agak muda (1 hari!) dan (dengan demikian) tidak memiliki beberapa fitur, tetapi terlihat menjanjikan - akan menonton dengan cermat.

@cjk terima kasih atas umpan baliknya, fitur apa yang Anda suka? Kalau bisa lebih spesifik.

Cepat q. Apa keuntungan menggunakan perpustakaan ini daripada nodejs http asli?

@cgarrovillo Kode Kecil => Lebih Banyak Dampak

coba url-request , lihat saja kumpulan fitur dan kemungkinan

@cjk terima kasih atas umpan baliknya, fitur apa yang Anda suka? Kalau bisa lebih spesifik.

@Debdut saya sedang memikirkan fitur seperti:

1. Autentikasi
2. HTTP2
3. Dukungan proxy
4. Kompresi
5. Penanganan waktu habis
6. kait khusus
7. Permintaan pembatalan

Tidak jelas dari dokumen url-request mana yang didukung dan bagaimana caranya.

Namun, saya menyukai banyak contoh yang Anda berikan!

Tetap gunakan permintaan sampai berhenti berfungsi.

Dalam rxjs sudut dan yang dapat diamati sangat baik

Adakah lib yang memiliki toples kue seperti permintaan?

Pengujian Mendapat perpustakaan HTTP dengan simpul merah. ✋.

• npm terpasang
• ditambahkan ke konteks
• Sekarang di editor aliran, impor _got_ di fungsi js saya

Hasil
Bekerja dengan baik saat melakukan permintaan HTTP. (membuat tes tunggal).
GAGAL saat melakukan permintaan HTTPS. Saya mendapatkan :
RequestError: connect ECONNREFUSED 127.0.0.1:443

Pada awalnya saya pikir ini adalah sesuatu yang berhubungan dengan node-red env. Kemudian ditemukan ini adalah masalah terbuka di mendapat repo: https://github.com/sindresorhus/got/issues/1414 . 👎.
Dan menurut saya, itu cukup alasan untuk menggunakan _axios_ sebagai gantinya. ✅.
Hanya ingin kau tahu.

@damdauvaotran Adakah lib yang memiliki toples kue seperti permintaan?

Lihat got.js, panduan migrasi .

Mengapa gaxios tidak disebutkan?

FWIW, berikut adalah tautan tren NPM yang membandingkan semua proyek yang disebutkan di atas. Meskipun bukan satu-satunya faktor yang terlibat dalam keputusan, popularitas cukup penting bagi kami dan di sebagian besar proyek.
Pada tulisan ini, node-fetch adalah alternatif yang paling populer.

Menarik @ericsnap ... node-fetch dan axios adalah yang pertama dan ketiga (hampir kedua) dalam popularitas.

Dan saya perhatikan strapline berikut dari gaxios docs :

Klien permintaan HTTP yang menyediakan antarmuka seperti aksio di atas pengambilan simpul

Jadi gaxios menggabungkan dua perpustakaan paling populer. Saya telah mengonversi ke gaxios dan sangat menyenangkan untuk digunakan.

pengambilan simpul / aksio

https://www.npmtrends.com/node-fetch-vs-got-vs-axios-vs-superagent

Setelah meninjau banyak alternatif permintaan saat ini, saya telah mengambil risiko @sindresorhus ke got. Butuh waktu sekitar satu hari untuk membiasakan diri dengan API (dokumen sudah cukup baik). Saya pernah mengalami penurunan LoC yang signifikan karena extend dan setting yang begitu banyak di satu tempat, maka call sights dan error handling biasanya hanya segelintir LoC. Rasanya jauh lebih apik dari request, request-promise, request-promise-native dance. Sebuah set fitur yang hebat juga. Kerja bagus dan terima kasih banyak @sindresorhus!

Saya tidak menantikan migrasi, tetapi saya merasa jauh lebih bersih sekarang.