بصفتي رجلًا يركز على الواجهة الأمامية والذي يقوم أيضًا بتنفيذ node.js من وقت لآخر ، فقد كانت أكسيوس أذهب إليه.
Easy API ، من Facebook ، تعمل على المتصفحات والعقدة؟ منجز

في مناقشة حديثة مع mikeal ، لقد عمدت إلى المحاولة. بصفتك مطورًا لـ Node.js كان يستخدم الطلب لفترة من الوقت الآن ، كان الانحراف بالتأكيد انتقالًا سهلاً - موصى به للغاية 💖

reconbot قد ترغب في إضافة got ، إبرة و urllib .

حسنًا ، من الخطأ الترويج لمكتبتي الصغيرة هنا ، ولكن نظرًا لأن هذا هو الهدف من المشكلة ، فإليك ما يلي: يعد طلب الإنشاء أمرًا وظيفيًا ، و 0 deps HTTP مع دعم للوعود والتدفق ومجموعة من خيارات مفيدة أخرى ، معظمها قريب جدًا من الخيارات الموجودة في الطلب.

أنا أيضا كتبت مقال عن ذلك. الفكرة العامة هي أنه يتم تشجيع الجميع على تكوين عملاء HTTP خاص بهم ، ومصممين خصيصًا لتلبية احتياجاتهم الخاصة.

بالنسبة لحجم الحزمة ، ليس لدي أي فكرة ، ولكن يجب أن يكون صغيرًا جدًا ، على الرغم من أن هذا العميل لم يتم تصميمه أبدًا ليتم استخدامه في المتصفح.

قد يكون من الجيد إضافة الأعمدة التالية إلى الجدول:

• عدد النجوم في Github (نعم ، أعرف بالفعل أن هذا ليس العامل الوحيد عند اختيار lib)
• عدد التنزيلات npm (ربما أسبوعيًا ، نفس الإحصائيات مثل موقع الويب npm ، ونعم أعرف بالفعل أن هذا ليس العامل الوحيد عند اختيار lib)

عند وضع هذه الأرقام جنبًا إلى جنب ، تحتوي بعض الليبز على آلاف النجوم وملايين التنزيلات أسبوعيًا ، مقابل البعض الآخر بالمئات.

سنتان ، لا بأس من التجاهل والمضي قدمًا ، ولا داعي لتصحيح التعليق أو الاعتراض عليه.

csantanapr أوافق ، قد يكون من المفيد مقارنة مجموعات الميزات أيضًا. دعم الوكيل ، ودعم ذاكرة التخزين المؤقت ، وميزات المصادقة وما إلى ذلك. إذا كنت تستخدم ميزة معينة للطلب وتحتاج إلى العثور عليها في مكان آخر ، فسيكون هذا هو الوقت المناسب للتحدث عنها.

axios يحصل على تصويتي ، خاصةً كصاحب الواجهة الأمامية.

يستحق نظرة: ky (الواجهة الأمامية) و ky-universal (متماثل الشكل)

مستخدم Axios هنا. بهذه الطريقة ، يمكن لجميع فرقنا استخدام المكتبة نفسها بغض النظر عن البيئة: المتصفح أو nodejs (يعمل في خادم أو بدون خادم). بحالة جيدة للغاية ، وجميع أفراد شعبنا يحبونها.

لدينا مقارنة جيدة بين got و request و node-fetch و axios و superagent في الملف التمهيدي got : https://github.com/sindresorhus/got#comparison
(نرحب بالعلاقات العامة إذا رأيت أي أخطاء. لقد حاولنا إبقائها محايدة قدر الإمكان)

حصلت أيضًا على دليل ترحيل للانتقال من request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

بالنسبة لي ، أميل إلى عمل أغلفة حول إحضار api ، لذا فإن إحضار العقدة هو my goto. على الرغم من الجوانب السلبية ، عادةً ما أقوم بتحميلها على عقدة global.fetch ، لذا يمكنني الاعتماد عليها دائمًا ، كما هو الحال في المتصفح (عبر polyfill للمتصفحات القديمة). يمكن أيضًا استخدام isomorphic-fetch وهو عبارة عن غلاف تقريبًا حول node-fetch للعقدة ، و polyfill (أو الجلب المتاح بالفعل) في المتصفح. نظرًا لأنني لست مضطرًا إلى دعم المتصفحات القديمة ، فأنا فقط أستخدم المتصفحات العالمية ، وأنشئ العالمية للاستخدام في العقدة.

مرحبًا ، Wreck (https://www.npmjs.com/package/wreck) هو ما أستخدمه

أفضل شيئًا يحاكي واجهة برمجة تطبيقات الجلب على العميل. Libs مثل axios و superagent وما إلى ذلك هي تجريدات ذات مستوى أعلى أعلى مكتبة الطلبات القياسية. كبديل لمكتبة الطلبات منخفضة المستوى ، أود أن أرى شيئًا يعكس المكافئ منخفض المستوى على العميل لأغراض تطوير js الشاملة. يمكن لـ Libs مثل axios و superagent إعادة تنفيذ أنفسهم فوق ذلك ، ويمكن لمستخدميها الاستمرار في استخدامها ، ولكن لا ينبغي اعتبار هؤلاء أساسيين لهذا الغرض.

Velveeta ذهبت ونظرت في أكسيوس كودبيز ولا أرى أي دليل على أنها تستند إلى "مكتبة الطلبات القياسية ذات المستوى الأدنى". من فضلك قل لي كيف توصلت إلى هذا الاستنتاج؟

مقارنة sindresorhus هي إلى حد بعيد الطريقة الأفضل من القائمة أعلاه. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch لبنة بناء منخفضة المستوى مناسبة لمعظم العملاء. أنا أحب أن أرى رقاقة الطلب على أساس الجلب.

أود أن أختتم عملية الجلب باستخدام API أجمل في أي يوم. حسنًا ، أعتقد أن هذه مجرد مسألة تفضيل ، ولكن التلميح إلى أن واجهة برمجة تطبيقات الجلب رائعة لمجرد أنها معيار فعلي في المتصفحات أمر خاطئ تمامًا. أعلم أنه أقل ضوضاء أن تكون متشابهًا على كلا الجانبين ، لكن هذا لا يجعله أفضل.

هناك r2 بواسطة mikeal نفسه. من المفترض أن تكون خليفة روحي لـ request . يحتوي على Promise API وهو مضغوط 16 كيلو بايت.

قد تعمل Axios بشكل جيد في المتصفح ، لكن هذه لم تكن تجربتنا معها على Node.js. أيضًا ، لست متأكدًا مما إذا كان يتم صيانته بنشاط بعد الآن.

@ kreig303 لم ألق نظرة على الأجزاء الداخلية من الأكسيوس ، لذلك لم أكن على علم بذلك. يبدو أنه يعتمد حاليًا على XHR's العادية ، وهو أمر منطقي ، نظرًا لأنه حل لكل من طلبات العميل والخادم. لقد قصدت ببساطة أن الأكسيوس غنية بالميزات ، وينبغي النظر في شيء أكثر بقليل من العظام المجردة للوحدة التأسيسية كبديل للطلب ، ثم السماح للمزيد من الميزات الغنية بالبناء فوق ذلك إذا رغبوا في ذلك. لقد اخترت شيئًا يعكس واجهة برمجة تطبيقات الجلب على وجه التحديد لأغراض الحصول على واجهة برمجة تطبيقات متسقة على كل من العميل والخادم (مثل XHR's التي تعمل بشكل أساسي) ، ولأنها الخلف المنطقي لـ XHR. إذا كان المطلوب هو غلاف API أجمل ، فهناك الكثير من الفرص لتغليفه وإصدار مكتبة أخرى باستخدام واجهة برمجة التطبيقات المثلى ، لكنني جميعًا من أجل تكافؤ الميزات وواجهة برمجة التطبيقات بين العميل والخادم أينما يمكن القيام بذلك.

حسنًا ، إحدى المشكلات التي نطلبها هي ميزات كثيرة جدًا ، وحالة مكشوفة أكثر من اللازم ، حتى تلك التي تعتبر داخلية. إنها لعنة ونعمة في نفس الوقت أن يكون لديك الكثير من الميزات. إنها نعمة لأنها تحظى بشعبية كبيرة ، وكانت الأولى. إنها لعنة لأنه بدون بذل قدر هائل من الجهد المستمر للحفاظ على نظام التعليمات البرمجية نظيفًا ومباشرًا ومثيرًا بشكل عام للعمل معه ، يموت المشروع في النهاية. وهذه ليست مشكلة طلب ، إنها وجهة نظر المستخدم الخاصة برغبته دائمًا في إخراج شيء ما من طبقته الخاصة ، وبدلاً من ذلك وضعه تحت الغطاء في مكان آخر.

حسنًا ، أعتقد أن الأكسيوس لها نفس الإيمان ..

إذن ما يمكننا فعله جميعًا هو بذل بعض الجهد على الأقل لفهم كيفية عمل العجلة ، ثم محاولة التفكير في كل مهمة فردية في متناول اليد ، ومعرفة أي عجلة تناسبها بشكل أفضل.

ofrobots هذه لقطة شاشة انتقائية لمثل هذه المكتبة الشائعة الاستخدام. هنا لي:

FWIW لا أذكر ما إذا كنت قد استخدمته كمحرر خلفي ، لذا فأنا لست في وضع يسمح لي بالتحقق من ادعاءاتك (إلا إذا كان لديك حالة استخدام خاصة لم يتم تغطيتها).

Velveeta أرى إلى أين أنت ذاهب مع هذا ، لا أعرف ما إذا كانت meta-libs هي السبيل للذهاب.

تصويتي من الواجهة الأمامية هو axios . صغيرة ومستقرة ويمكن التنبؤ بها.

أنا شخصياً أستخدم wretch لكل من مشروعي FE- و BE - ويرجع ذلك أساسًا إلى أن واجهة برمجة التطبيقات بديهية حقًا.

غلاف حول الجلب - يعمل بشكل جيد مع node-fetch أيضًا.

بالنسبة للأشخاص الذين يسعون للحصول على تجربة تشبه axios بالإضافة إلى fetch API ، هناك gaxios . تم إنشاؤه بواسطة مطور في Google ويقوم حاليًا بتشغيل جميع تفاعلات HTTP لعميل Node.js الخاص بواجهة برمجة تطبيقات Google ، لذلك يبدو من الآمن اعتباره تم اختباره واستخدامه بنشاط!

(👋 في @ JustinBeckwith)

مرحبًا ، Wreck (https://www.npmjs.com/package/wreck) هو ما أستخدمه

إنه أيضًا عميل http الأساسي لإطار عمل hapijs. التنفيذ نظيف للغاية للإقلاع.

هناك r2 بواسطة mikeal نفسه. من المفترض أن تكون خليفة روحي لـ request . يحتوي على Promise API وهو مضغوط 16 كيلو بايت.

لا يتم الحفاظ على تلك المكتبة. إذا كنت تريد واجهة برمجة تطبيقات مشابهة ، فإنني أوصي بـ ky ، وهو ~ 1 كيلوبايت مصغرًا ومضغوطًا ، ويحتفظ به نفس الأشخاص مثل got .

قد تعمل Axios بشكل جيد في المتصفح ، لكن هذه لم تكن تجربتنا معها على Node.js. أيضًا ، لست متأكدًا مما إذا كان يتم صيانته بنشاط بعد الآن.

أستخدم المحاور في Node برضا كبير. بشكل أساسي في لامدا ولأنها تتميز بأنها غنية ولكنها لا تأتي مع سلسلة تبعية مجنونة. ofrobots ما هي تجربتك معها في Node؟

بصفتي شابًا يركز على الواجهة الأمامية ويقوم أيضًا بعمل عقدة js من وقت لآخر ، كانت البديهيات هي التي أذهب إليها. Easy API ، من Facebook ، تعمل على المتصفحات والعقدة؟ منجز

لم أكن أعرف أنه فيسبوك؟ لكن نعم ، هذه هي مكتبة goto الخاصة بي لجميع عمليات الوصول إلى واجهة برمجة التطبيقات.

نحن نستخدم هذه المكتبة tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. صغير ، يعمل في المتصفح وعلى الخادم ومبني على مفهوم المكونات الإضافية. تم إنشاء المكتبة للسماح بالاستخدام المتزامن لعدة أنواع من التخزين المؤقت المعقد.

هل استخدم أي شخص عميل الراحة المكتوب من Microsoft؟ يبدو وكأنه حزمة جيدة الصيانة مكتوبة في TypeScript (بالنسبة لي إنها إضافة كبيرة).

يجب أن يتضمن هذا wreck (من النظام البيئي hapi )

لقد استخدمت مؤخرًا https://github.com/grantila/fetch-h2 بنجاح كبير

هل يوجد حاليًا أي بديل متوافق معروف؟ تم دمجه في KOA ويعطيني مشكلة في التدفق

كما ذكر في بداية الإصدار ، كنت أعمل على مكتبة أخرى أفضل الآن استخدامها تسمى bent .

لم يتم تصميم bent لفترة من الوقت للعمل في المتصفح. نظرًا لأن واجهة برمجة التطبيقات مستقرة جدًا الآن ، فقد قضيت بعض الوقت في كتابة إصدار متصفح أعلى fetch . بدلاً من محاولة تصفح إصدار Node.js ، فإن إصدار المتصفح هو نقطة الدخول الخاصة به في package.json.

حسنًا ، يوجد دعم للمتصفح الآن bent وهو جيد جدًا:

• صفر تبعيات أو polyfill (مبني بالكامل على fetch و ArrayBuffer ، لذلك لا يوجد حاجز أو دفق polyfill ولا ديس للتجميع)
• حزمة حزمة الويب 2K تقريبًا غير مصغرة أو مضغوطة (يجب أن يخبرني أحدهم بما هو هذا بعد أدوات الضغط والصغير المفضلة لديهم).
• اجتازت جميع الاختبارات الكروم بدون رأس ، والذي يتمتع بتغطية 100٪ في إصدار Node.js (لا يزال ليس لديه طريقة رائعة لإجراء اختبار تغطية المتصفح الآلي)

هذا شيء عظيم mikeal

تضمين التغريدة :)

يمكن أن تتسبب Axios في تعطل خدمة العقدة الخاصة بك: https://github.com/axios/axios/issues/1804

بالنسبة لي ، أهم الاهتمامات هي:

• هل يعمل مع الحد الأدنى من التكوين في بيئة شركتي؟ (العوامل المساهمة: وكلاء الشركة عبارة عن HTTP لأهداف HTTP و HTTPS ، وليس كل الوكلاء يتعاملون مع جميع الشهادات بشكل صحيح ، بنفس الطريقة ، ...)
  
  
  
  • منعني هذا بشكل خاص من إيقاف تشغيل الطلب لمدة عام أو نحو ذلك.
  
  
• هل يدعم البث ، للحالات التي أحتاج فيها ، على سبيل المثال ، إلى تحميل / تنزيل ملف الوكيل؟

بعد ذلك ، لا أهتم بالشكل الذي تبدو عليه الواجهة طالما أن العمليات الأكثر شيوعًا مريحة. أنا أيضًا لست مهتمًا بالحجم وجانب الخادم ، على الرغم من أن هذا مهم إذا كنت تريد إعادة استخدام نفس المكتبة على كلا الطرفين.

تحرير: Yeeeaaaah لا أستطيع أن أقول بالضبط ألومك هناك.

تحرير 2: أعتقد أنني سألقي نظرة على node-libcurl .

joedski ya ، عناصر الوكيل غير مدعومة على نطاق واسع خارج الطلب. و TBH ، نظرًا لحجم العمل الذي استغرقته للحصول على هذا العمل ودعمه ، لست متفاجئًا من عدم رغبة أي شخص في القيام بذلك ، بما في ذلك أنا ؛) لقد فعلت ذلك مرة واحدة ولا أقفز بالضبط للكتابة مرة أخرى لعني 🤷🏽‍♀️

أخيرًا ، بدأت في استخدام مكتبة node-libcurl لتقديم الطلبات من nodejs. لأنه يستخدم مكتبة curl أصلية ، وهي ناضجة جدًا وتم اختبارها لسنوات في الإنتاج. إنه يعمل بشكل لا تشوبه شائبة مع جميع أنواع الوكلاء ، وعمليات إعادة التوجيه ، وله واجهات واعدة ودفق.

طلب صغير (> 1 مليون تنزيل أسبوعيًا)

الاستبدال الفوري للطلب ، ولكنه أصغر بكثير - وخيارات أقل. يستخدم node-fetch تحت الغطاء. انقلها حيث ستستخدم request .

تم الإبلاغ عن node-fetch بشكل غير صحيح ولم يتم الإبلاغ إلا عن إصدار "المتصفح" (متغلبًا على نقطة قائمة _Node.js_). هذا ما يبدو أنه تم قياسه بشكل خاطئ:

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

بدلاً من ذلك ، يجب قياس أيٍّ من هذين:

• 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

هم في كل مكان ~ 40kb

تم الإبلاغ عن unfetch أيضًا بشكل غير صحيح:

• تقول الصفحة الرئيسية أن "الاستخدام في Node.JS يتم التعامل معه من خلال isomorphic-unetch" ، لذلك يجب الإبلاغ عن الجمع بين الاثنين.
• يستخدم isomorphic-unfetch node-fetch ( code ، docs ) لـ Node.js ، لذا يجب أن يكون حجمها المبلغ عنه على الأقل حجم node-fetch (انظر تعليقي السابق).

نظرًا لأنه تم طرحه كثيرًا ، يجب أن أتحدث قليلاً عن تجربتي مع node-fetch .

بادئ ذي بدء ، إنه إنجاز كبير. إن مقدار الكود والجهد الهندسي المبذول فيه أكبر بكثير مما قدمناه في أي وقت مضى. يبدو fetch وكأنه واجهة برمجة تطبيقات صغيرة وأعتقد أن الناس يفترضون أن الجهد المبذول لتوفير واجهة برمجة تطبيقات متوافقة في Node.js اسمي ، لكنه في الحقيقة ليس كذلك.

نتيجة لذلك ، قاعدة الشفرة ضخمة. إنها تبعية كبيرة في Node.js ، والتي من المحتمل ألا تراها على الإطلاق في حزم المستعرضات ، لكن الأمر ليس كما لو أن حجم التبعية ليس مشكلة في Node.js ، لا سيما في البيئات التي لا تحتوي على خادم.

لا يمكن الاستغناء عن node-fetch عند الاختبار لأنه يقوم بكافة أعمال محاكاة واجهات برمجة التطبيقات للمتصفح بالكامل ، ولكن إذا كنت تستخدمه في أحد التطبيقات ، حتى إذا كان يتم تشغيله في Node.js وفي المتصفح ، فهو فقط الكثير من التعليمات البرمجية والكثير من المراوغة يستحق كل هذا العناء.

IMO ، النهج الصحيح في هذا الوقت للمكتبة التي تريد أن تكون عميل http في كل من Node.js والمتصفحات هو تنفيذ واجهة برمجة تطبيقات موحدة مع تنفيذ مقسم باستخدام fetch في المتصفح و require(‘http’) في Node.js. يجب ألا تستهدف التطبيقات وعملاء http fetch أو require(‘http’) مباشرةً ويجب ألا تعتمد على محاكاة واجهات برمجة التطبيقات هذه على أي من الجانبين. هذا في الواقع أسهل كثيرًا مما تعتقد ، كما ترى في تنفيذ bent وهو صغير بشكل لا يصدق https://github.com/mikeal/bent/tree/master/src

mikeal أواجه صعوبة في التربيع

نتيجة لذلك ، قاعدة الشفرة ضخمة. إنها تبعية كبيرة في Node.js ، والتي من المحتمل ألا تراها على الإطلاق في حزم المستعرضات ، لكن الأمر ليس كما لو أن حجم التبعية ليس مشكلة في Node.js ، لا سيما في البيئات التي لا تحتوي على خادم.

بحجم حزمة يبلغ 0.4 كيلو بايت مدرج في OP ، ما هو الأصغر من بين جميع البدائل المعطاة؟

domenic يعد تعقيد محاكاة واجهة برمجة التطبيقات للمتصفح هو المشكلة الرئيسية ، فهو يحتوي على الكثير من التعليمات البرمجية غير الضرورية والمراوغة عند محاولة التصحيح. لديك Blob API ، لديك الكثير من التنظيم لـ body ، لديك ما يقرب من 400 سطر من header marshalling ، وهذا لا ينظر حتى إلى واجهة برمجة التطبيقات الفعلية التي يتم كشفها.

كما قلت ، إنه مثير للإعجاب ، ولكنه أيضًا مجرد الكثير من التعليمات البرمجية المقتضبة والذكية وغير الضرورية في النهاية إذا كنت تريد فعل أي شيء باستثناء محاكاة fetch API.

mikeal لم تذكر حتى أن هناك عددًا كبيرًا من التعليمات البرمجية المطلوبة لجلب العقدة لتكون متوافقة بنسبة 100٪ مع واجهة برمجة تطبيقات الجلب: فهي لا تدعم التدفقات القابلة للقراءة والقابلة للكتابة من what-wg (شيء تحتاجه عند محاكاة البيئات مثل عمال Cloudflare.

حسنًا ، ما زلت لا أفهم تمامًا كيفية تربيع "طن" من الكود "غير الضروري في النهاية" بـ "0.4 كيلو بايت ، أقل من كل إدخال آخر على الطاولة و 0.25 ضعف حجم الانحناء " (والذي يُفترض أنه "الصحيح" نهج "و" صغير بشكل لا يصدق ").

domenic هل تقارن حجم حزمة المتصفح؟ أنا أتحدث عن مدى تعقيد تصحيح هذه الأخطاء في Node.js. في المتصفح ، أتوقع أن يكون معظم رمز node-fetch غير موجود ، لذلك لا أفهم حقًا ما تقارنه.

أقارن القيمة في OP ؛ لست متأكدًا من كيفية قياس ذلك. ربما لم يتم قياسها بشكل صحيح ، والتي ستكون معلومات جيدة لتحديث OP بها!

domenic ah نعم ، هذه كلها أحجام لحزم المتصفح ، وبما أن المنشور قديم جدًا ، فقد يكون العديد منها قديمًا على الرغم من أن الرقم bent لا يزال قريبًا بدرجة كافية.

@ root / request - بديل أقل بنسبة 80/20 مكتوبًا في 500 LoC ، وتبعيات صفرية:

تم إنشاؤه واختباره وفقًا لسلوك request.js عن قصد.

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

مرحبا جميعا! أقوم ببعض البحث للعثور على بديل مناسب لطلب لمشاريعي. في الوقت الحالي ، هذا ما جمعته معًا: https://github.com/emanuelcasco/http-packages-benchmark

التوصيات والآراء مرحب بها بالطبع!

Às request الآن مهمل رسميًا ، لا يمكنني التأكيد أكثر على أهمية اقتراح postman-request رسميًا كبديل كامل للميزة مقابل request ، وربما @root/request لأولئك الذين يحتاجون فقط إلى مجموعة فرعية محدودة من request ولا يهتمون على سبيل المثال. تيارات.

يسمح هذا لأي مشرف حزمة بإسقاط request والتخلص من رسالة الإيقاف المزعجة دون قضاء أكثر من بضع دقائق من وقت التطوير في هذه المشكلة ، ودون الحاجة إلى إعادة تشكيل مكتبتهم أو تطبيقهم بالكامل. لقد استغرق الأمر بعض الوقت والإحباط لمعرفة ما إذا كانت هذه البدائل موجودة.

ونعم ، أدرك أن مجرد "الإهمال" لا يكسر أي شيء. نعم ، من الناحية الفنية لا يزال بإمكان الجميع استخدام request وربما يستمر في استخدامه لعقود قادمة. هذا ليس ما يفترض استخدام الإهمال من أجله. من المفترض أن يكون الإهمال بمثابة دعوة للعمل ، و "فترة سماح" للأشخاص لترقية كودهم إلى أن يقرر شخص ما في مكان ما سحب قابس.

أنا أكره ذلك حقًا عندما يتم استخدام "الإهمال" فقط لوضع علامة على "نهاية الدعم" أو "نهاية الصيانة" ، كما يبدو هنا. لكنني سأكون منزعجًا كثيرًا عند شراء هذا ، إذا كان هناك بديل مدعوم رسميًا ومُحافظ عليه بشكل نشط ومتكامل للميزة مثل postman-request .

في الواقع ، هل فكر أي شخص في تسليم صيانة هذه الحزمة إلى فريق ساعي البريد؟ بدلاً من إهمال request ، لماذا لا تقترح عليهم نقل postman-request إلى request والسماح لهم بأن يصبحوا المشرفين الرسميين الجدد؟

آسف للترويج لمكتبتي الصغيرة هنا

مصممة لتستخدم فقط في 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);

لقد وجدت أن Wretch هو الخيار الأفضل إذا كنت تقوم ببناء SPA مطبعية حديثة ، بالنظر إلى أنها مكتوبة بلغة TS لتبدأ بها. ميزة فعالة تساوي Axios وتدعم البرامج الوسيطة الإضافية . أعتقد أن API أجمل قليلاً في مكانين مقارنة بـ Ky أيضًا.

أي من هذه الدعم http2؟

sakalys got لديه دعم HTTP2 تجريبي ، والذي سيكون مدمجًا ومستقرًا في الإصدار الرئيسي التالي (قريبًا).

قريب من الاستبدال؟

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

حزين حقًا لرؤية هذه المكتبة يتم إهمالها. أنا أحب أكسيوس ، ولكن عدو بعض الأغراض ، كان الطلب هو خياري القبضة.

أي من هذه طلبات الدعم توقيت؟ مثل الوقت لأول بايت ، وتأخر الشبكة وهلم جرا؟
أنا أستخدم مكتبة الطلبات لمشروع ما والتوقيت أمر بالغ الأهمية لذلك.

تقدم Google gaxios https://github.com/googleapis/gaxios - axios api over node-fetch

لدينا مقارنة جيدة بين got و request و node-fetch و axios و superagent في الملف التمهيدي got : https://github.com/sindresorhus/got#comparison
_ (نرحب بالعلاقات العامة إذا رأيت أي أخطاء. لقد حاولنا إبقائها محايدة قدر الإمكان) _

حصلت أيضًا على دليل ترحيل للانتقال من request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

لقد تم _moved_ إلى دليل ترحيل Got للانتقال من request إلى:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

هل أقترح إضافة طلب ساعي البريد؟ سأحاول هذا في مشروعي القادم. على كل حال هذا ما قيل عنها في التوثيق ...

هذه شوكة لوحدة الطلب الممتازة ، والتي تُستخدم داخل Postman Runtime. يحتوي على بعض إصلاحات الأخطاء التي لم يتم إصلاحها في الطلب.

Redaxios مثل 800 بايت باستخدام الجلب الأصلي https://github.com/developit/redaxios

يا الهي !! كنت أفكر في هذا من 3 ساعات فحصت الكود مرارًا وتكرارًا. وأعطاني الخطأ 404 ، شعرت بالإحباط. شكرا جزيلا. أعتقد أنني سأذهب مع Fetch.

https://www.npmjs.com/package/teeny-request هو خيار آخر تستخدمه Google APIs.

مثل الطلب ، ولكن أصغر بكثير - وبخيارات أقل. يستخدم node-fetch تحت الغطاء. ضعها في المكان الذي ستستخدم فيه الطلب. يحسن التحميل ووقت التحليل للوحدات النمطية.

ما هو الأفضل node-fetch أو النسخة المتشعبة من requests والتي يتم صيانتها الآن بواسطة PostMan. لقد بدأت للتو رحلة Node الخاصة بي لذا أطلب شيئًا بسيطًا.

يبدو أن مهلة axios لم يتم إصلاحها أبدًا

لقد فوجئت جدًا بعدم رؤية فين هنا.

https://github.com/ethanent/phin

ماذا عن url-request ؟

https://github.com/Debdut/Url

ماذا عن url-request ؟

https://github.com/Debdut/Url

لا يزال صغيرًا بعض الشيء (يوم واحد!) وبالتالي يفتقر إلى بعض الميزات ، لكنه يبدو واعدًا - سوف يراقب عن كثب.

cjk شكرًا على التعليقات ، ما الميزات التي ستعجبك؟ إذا كنت يمكن أن تكون أكثر تحديدا.

سريع ف. ما فائدة استخدام هذه المكتبات بدلاً من nodejs http الأصلي؟

cgarrovillo الرمز الصغير => تأثير أكبر

جرب طلب url ، ما عليك سوى إلقاء نظرة على مجموعة الميزات والإمكانيات 🤟

cjk شكرًا على التعليقات ، ما الميزات التي ستعجبك؟ إذا كنت يمكن أن تكون أكثر تحديدا.

Debdut أفكر في ميزات مثل:

1. المصادقة
2. HTTP2
3. دعم الوكيل
4. ضغط
5. التعامل مع المهلة
6. خطاطيف مخصصة
7. طلب الغاء

ليس من الواضح من مستندات url-request أي من هؤلاء يتم دعمه وكيف.

ومع ذلك ، فقد أحببت الأمثلة العديدة التي قدمتها!

فقط استمر في استخدام الطلب حتى يتوقف عن العمل.

في rxjs الزاوي والملاحظة ممتازة

أي ليب لديه جرة ملفات تعريف الارتباط مثل الطلب؟

جربت مكتبة HTTP ذات العقدة الحمراء. ✋

• تثبيت npm
• يضاف إلى السياق
• الآن في محرر التدفق ، تم استيراد _got_ في دالة js الخاصة بي

نتائج
يعمل بشكل جيد عند تنفيذ طلبات HTTP. (تم إجراء اختبار واحد).
فشل ❌ عند تنفيذ طلبات HTTPS. أنا أخذت :
RequestError: connect ECONNREFUSED 127.0.0.1:443

في البداية اعتقدت أن هذا كان شيئًا متعلقًا ببيئة العقدة الحمراء. اكتشفت لاحقًا أن هذه مشكلة مفتوحة في إعادة الشراء: https://github.com/sindresorhus/got/issues/1414. 👎
وفي رأيي ، هذا سبب كافٍ للذهاب إلى _axios_ بدلاً من ذلك. ✅
فقط أردت إعلامك.

damdauvaotran أي lib لديه جرة ملفات تعريف الارتباط مثل الطلب؟

راجع got.js ، دليل الترحيل .

لماذا لم يذكر gaxios ؟

FWIW ، هنا رابط اتجاهات NPM يقارن جميع المشاريع المذكورة في الأعلى. على الرغم من أنها ليست العامل الوحيد في اتخاذ القرار ، إلا أن الشعبية مهمة جدًا بالنسبة لنا وفي معظم المشاريع.
حتى كتابة هذه السطور ، يعد node-fetch البديل الأكثر شيوعًا.

ericsnap مثير للاهتمام ... node-fetch و axios هما الأول والثالث (تقريبًا الثاني) من حيث الشعبية ، على التوالي.

وألاحظ الشريط التالي من مستندات gaxios :

عميل طلب HTTP يوفر محاور مثل الواجهة فوق node-fetch

لذلك يجمع Gaxios بين اثنتين من أكثر المكتبات شهرة. لقد كنت أقوم بالتحويل إلى gaxios وهو ممتع للغاية للاستخدام.

عقدة الجلب / المحاور

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

بعد مراجعة مجموعة من بدائل الطلب الحالية ، بدأت في الحصول على sindresorhus . لقد استغرق الأمر يومًا تقريبًا للتعود على واجهة برمجة التطبيقات (كانت المستندات جيدة إلى حد ما). لقد شهدت انخفاضًا كبيرًا في LoC بسبب extend وإعداد الكثير في مكان واحد ، ثم عادةً ما تكون مشاهد المكالمة ومعالجة الأخطاء مجرد حفنة من LoC. إنه شعور أكثر رقة من الطلب والطلب والوعد والرقص الأصلي. مجموعة ميزات رائعة أيضًا. عمل عظيم وشكرا جزيلاsindresorhus!

لم أكن أتطلع إلى الهجرة ، لكني أشعر بأنني أكثر نظافة الآن.