때때로 node.js도 하는 프론트엔드에 집중하는 사람으로서, axios는 제가 가본 곳입니다.
Facebook의 Easy API는 브라우저와 노드에서 작동합니까? 완료

@mikeal 과의 최근 토론에 따르면 Bent가 시도했습니다. 한동안 request를 사용해 온 Node.js 개발자로서, 벤트는 확실히 쉬운 전환이었습니다 - 적극 추천합니다 💖

@reconbot got , needle , urllib 를 추가하고 싶을 수도 있습니다.

글쎄, 내 자신의 작은 라이브러리를 여기에서 홍보하는 것은 일종의 잘못된 느낌이 들지만 그것이 문제의 목표이기 때문에 여기에 있습니다. request-compose 는 약속, 스트림 및 많은 다른 유용한 옵션은 대부분 요청에서 찾은 옵션과 매우 유사합니다.

나는 또한 그것에 관한 기사 를 썼습니다. 일반적인 아이디어는 모든 사람이 자신의 필요에 맞게 특별히 조정된 자신의 HTTP 클라이언트를 구성하도록 권장된다는 것입니다.

번들 크기에 관해서는 잘 모르겠지만 이 클라이언트는 브라우저에서 사용하도록 설계되지 않았지만 꽤 작아야 합니다.

테이블에 다음 열을 추가하는 것이 좋습니다.

• Github의 별 수(예, 라이브러리를 선택할 때 이것이 유일한 요소가 아니라는 것을 이미 알고 있습니다)
• npm 다운로드 수(매주, npm 웹사이트와 동일한 통계, 예, 라이브러리를 선택할 때 이것이 유일한 요소가 아니라는 것을 이미 알고 있습니다)

이 수치를 나란히 놓고 보면 일부 라이브러리는 매주 수천 개의 별과 수백만 개의 다운로드를 기록하지만 다른 라이브러리는 수백 개에 달합니다.

내 2센트, 무시하고 넘어가도 됩니다. 댓글을 수정하거나 이의를 제기할 필요가 없습니다.

@csantanapr 동의합니다. 기능 세트도 비교할 가치가 있습니다. 프록시 지원, 캐시 지원, 인증 기능 등. 요청의 특정 기능을 사용하고 다른 곳에서 찾아야 하는 경우 이에 대해 이야기할 좋은 시간이 될 것입니다.

axios 는 특히 프론트 엔드에서 내 투표를 얻습니다.

살펴볼 가치: ky (프론트엔드) 및 ky-universal (동형)

여기 Axios 사용자입니다. 그렇게 하면 모든 팀이 브라우저 또는 nodejs(서버 또는 서버리스에서 실행)와 같은 환경에 관계없이 동일한 라이브러리를 사용할 수 있습니다. 매우 잘 관리되어 있으며 모든 사람들이 그것을 좋아합니다.

$ got readme에서 got , request , node-fetch , axios , superagent 를 잘 비교했습니다. : https://github.com/sindresorhus/got#comparison
(부정확한 내용이 있으면 PR 환영합니다. 최대한 중립적으로 유지하려고 노력했습니다.)

Got에는 request 에서 이동하기 위한 마이그레이션 가이드도 있습니다. https://github.com/sindresorhus/got/blob/master/migration-guides.md

나를 위해, 나는 fetch api 주위에 래퍼를 만드는 경향이 있으므로 node-fetch가 나의 goto입니다. 부정적인 측면에도 불구하고 일반적으로 노드의 global.fetch 에 로드하므로 브라우저에서와 마찬가지로 항상 사용할 수 있다고 믿을 수 있습니다(이전 브라우저의 경우 폴리필을 통해). isomorphic-fetch 노드에 대한 node-fetch와 브라우저에서 fetch polyfill(또는 이미 사용 가능한 fetch)을 둘러싼 래퍼를 사용할 수도 있습니다. 레거시 브라우저를 지원할 필요가 없기 때문에 전역을 사용하고 노드에서 사용할 전역을 설정합니다.

Hey, Wreck(https://www.npmjs.com/package/wreck)는 내가 사용하는

클라이언트에서 가져오기 API를 모방하는 것을 선호합니다. axios, superagent 등과 같은 라이브러리는 표준 요청 라이브러리 위에 있는 더 높은 수준의 추상화입니다. 저수준 요청 라이브러리의 대체품으로 범용 js 개발을 위해 클라이언트에서 저수준에 상응하는 것을 미러링하는 것을 보고 싶습니다. axios 및 superagent와 같은 Lib는 그 위에 스스로를 다시 구현할 수 있으며 사용자는 계속 사용할 수 있지만 이러한 목적을 위한 기초로 간주되어서는 안 됩니다.

@Velveeta 가서 axios 코드베이스를 살펴보았는데 "저수준 표준 요청 라이브러리"를 기반으로 한다는 증거가 없습니다. 어떻게 이런 결론을 내리게 되었는지 말씀해 주십시오.

@sindresorhus 의 비교는 위의 내 목록보다 훨씬 더 나은 접근 방식입니다. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch 는 대부분의 클라이언트에 적합한 낮은 수준의 빌딩 블록입니다. 가져오기 기반 요청 심을 보고 싶습니다.

나는 언젠가 더 멋진 API로 가져오기를 포장할 것입니다. 글쎄요, 그것은 단지 선호도의 문제일 뿐이라고 생각하지만, 브라우저의 사실상의 표준이기 때문에 fetch API가 훌륭하다고 암시하는 것은 잘못된 것입니다. 나는 양쪽에 동형을 갖는 것이 소음이 적다는 것을 알고 있지만 그것이 더 좋아지지는 않습니다.

@mikeal 이 직접 만든 r2 가 있습니다. request 의 영적 후계자를 의미합니다. Promise API가 있으며 16kb로 압축되어 있습니다.

Axios는 브라우저에서 제대로 작동할 수 있지만 Node.js에서는 그렇지 않았습니다. 또한 더 이상 활발히 유지되고 있는지 잘 모르겠습니다.

@kreig303 저는 axios의 내부를 들여다보지 않아서 잘 몰랐습니다. 클라이언트와 서버 요청 모두에 대한 솔루션이기 때문에 현재 일반 XHR을 기반으로 하는 것 같습니다. 간단히 말해서 axios는 기능이 상당히 풍부하고 요청을 대체하는 것과 같은 기본 모듈에 대해 조금 더 기본적인 것을 고려하고 원하는 경우 기능이 더 풍부한 다른 라이브러리가 그 위에 빌드하도록 해야 합니다. 나는 클라이언트와 서버 모두에서 일관된 API를 가질 목적으로 특히 XHR의 논리적 계승자이기 때문에 가져오기 API를 미러링하는 것을 선택했습니다. 더 나은 API 래퍼가 필요한 경우 이를 래핑하고 최적의 API로 다른 라이브러리를 릴리스할 수 있는 기회가 많이 있지만, 가능한 모든 곳에서 클라이언트와 서버 간의 기능 및 API 패리티를 위해 최선을 다합니다.

우리가 요청한 문제 중 하나는 기능이 너무 많고 노출 상태가 너무 많다는 것입니다. 심지어 내부로 간주되는 항목도 있습니다. 많은 기능이 있다는 것은 저주이자 축복입니다. 그만큼 인기가 많고 처음이라서 다행이다. 코드베이스를 깨끗하고 간단하며 일반적으로 작업하기에 흥미진진한 상태로 유지하기 위한 엄청난 양의 지속적인 노력 없이는 프로젝트가 결국 죽기 때문에 저주입니다. 그리고 그것은 요청의 문제가 아니라 항상 자신의 레이어에서 뭔가를 꺼내고 대신 다른 어딘가에 담요 아래에 넣고 싶어하는 사용자 자신의 관점입니다.

뭐, axios도 같은 믿음을 가지고 있는 것 같은데..

따라서 우리 모두가 대신 할 수 있는 것은 바퀴가 어떻게 작동하는지 이해하는 데 최소한의 노력을 기울이고, 당면한 각 개별 작업을 통해 생각하고 어떤 바퀴가 가장 적합한지 확인하는 것입니다.

@ofrobots 는 널리 사용되는 라이브러리에 대한 약간의 선택적 스크린샷입니다. 여기 내 것:

FWIW 백엔드 라이브러리로 사용했는지 기억나지 않으므로 귀하의 주장을 확인할 수 있는 위치에 없습니다.

@Velveeta 나는 당신이 이것을 가지고 어디로 가고 있는지 알지만, meta-libs가 갈 길인지 모르겠습니다.

Frontend에서 내 투표는 axios 입니다. 작고 안정적이며 예측 가능합니다.

저는 개인적으로 FE 및 BE 프로젝트 모두에 wretch 를 사용합니다. 주로 API가 정말 직관적이기 때문입니다.

가져오기에 대한 래퍼 - 노드 가져오기와도 잘 작동합니다.

fetch API 위에 axios 같은 경험을 원하는 사람들을 위해 gaxios 가 있습니다. Google의 개발자가 구축했으며 현재 Google API의 Node.js 클라이언트의 모든 HTTP 상호 작용을 지원하므로 전투 테스트를 거쳐 적극적으로 사용되는 것으로 간주하는 것이 안전해 보입니다!

(👋 @JustinBeckwith에서)

Hey, Wreck(https://www.npmjs.com/package/wreck)는 내가 사용하는

또한 hapijs 프레임워크의 기본 http 클라이언트이기도 합니다. 구현은 부팅하기에 매우 깨끗합니다.

@mikeal 이 직접 만든 r2 가 있습니다. request 의 영적 후계자를 의미합니다. Promise API가 있으며 16kb로 압축되어 있습니다.

해당 라이브러리는 유지되지 않습니다. 비슷한 API를 원한다면 ky 를 추천합니다. $ got 와 같은 사람들이 유지 관리하는 ~1kb 축소 및 gzip 파일입니다.

Axios는 브라우저에서 제대로 작동할 수 있지만 Node.js에서는 그렇지 않았습니다. 또한 더 이상 활발히 유지되고 있는지 잘 모르겠습니다.

저는 Node에서 axios를 매우 만족스럽게 사용하고 있습니다. 주로 람다에서 주로 기능이 풍부하지만 미친 종속성 체인이 제공되지 않기 때문입니다. @ofrobots Node에서 사용한 경험은 무엇입니까?

노드 js를 때때로 수행하는 프론트엔드에 집중하는 사람으로서 공리는 제가 가본 곳입니다. Facebook의 Easy API는 브라우저와 노드에서 작동합니까? 완료

페이스북인줄 몰랐어? 하지만 예, 이것은 모든 API 액세스를 위한 내 goto 라이브러리입니다.

우리는 이 라이브러리 tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request를 사용합니다. 소형, 브라우저 및 서버에서 작동하며 플러그인 개념을 기반으로 합니다. 라이브러리는 여러 유형의 복합 캐싱을 동시에 사용할 수 있도록 만들어졌습니다.

Microsoft 의 typed-rest-client 를 사용한 사람이 있습니까? TypeScript로 작성된 잘 관리된 패키지처럼 보입니다(저에게는 큰 장점입니다).

여기에는 wreck ( hapi 생태계에서)가 포함되어야 합니다.

나는 최근에 https://github.com/grantila/fetch-h2 를 큰 성공으로 사용하고 있습니다.

현재 알려진 호환 가능한 교체품이 있습니까? KOA에 통합되어 스트림 문제가 발생합니다.

이 문제의 시작 부분에서 언급했듯이 저는 bent 라는 다른 라이브러리를 사용하고 있습니다.

한동안 bent 는 브라우저에서 작동하도록 설계되지 않았습니다. 이제 API가 꽤 안정적이기 때문에 fetch 위에 브라우저 버전을 작성하는 데 시간을 보냈습니다. Node.js 버전을 브라우저화하는 대신, 브라우저 버전은 package.json의 자체 진입점입니다.

이제 bent 에 브라우저가 지원되며 상당히 좋습니다.

• 종속성 또는 폴리필 없음(완전히 fetch 및 ArrayBuffer에 구축되므로 Buffer 또는 Stream 폴리필 및 번들할 deps 없음)
• ~2K webpack 번들 un-minified 또는 gzipped(누군가가 선호하는 minifier 및 압축기 다음에 이것이 무엇인지 알려야 함).
• 모든 테스트는 Node.js 버전에서 100% 커버리지가 있는 헤드리스 크롬에서 통과하고 있습니다(아직도 자동화된 브라우저 커버리지 테스트를 수행할 좋은 방법이 없음)

멋지네요 @mikeal

@csantanapr 감사합니다! :)

axios는 노드 서비스를 충돌시킬 수 있습니다: https://github.com/axios/axios/issues/1804

저에게 가장 큰 관심사는 다음과 같습니다.

• 회사 환경에서 최소 구성으로 작동합니까? (기여 요소: 회사 프록시는 HTTP 및 HTTPS 대상 모두에 대해 HTTP이며 모든 프록시가 동일한 방식으로 모든 인증서를 올바르게 처리하는 것은 아닙니다. ...)
  
  
  
  • 이것은 특히 1년 정도 전에 Request를 끄지 못하게 했습니다.
  
  
• 프록시 파일 업로드/다운로드가 필요한 경우 스트리밍을 지원합니까?

그 후에는 가장 일반적인 작업이 편리한 한 인터페이스가 어떻게 생겼는지 상관하지 않습니다. 나는 또한 서버 측의 크기에 지나치게 관심을 두지 않지만 양쪽 끝에서 동일한 라이브러리를 재사용하려는 경우 중요합니다.

편집: Yeeeaaaah는 정확히 내가 당신을 비난한다고 말할 수 없습니다.

편집 2: node-libcurl 살펴보겠습니다.

@joedski ya, 프록시 항목은 요청 외부에서 널리 지원되지 않습니다. 그리고 TBH, 그 일을 하고 그것을 지원하는 데 걸린 작업의 양을 고려할 때 저를 포함하여 아무도 그것을 하고 싶어하지 않는다는 사실이 놀랍지 않습니다. 다시 구부려 🤷🏽‍♀️

마지막으로 nodejs에서 요청을 만들기 위해 node-libcurl 라이브러리를 사용하기 시작했습니다. 매우 성숙하고 수년간 생산 테스트를 거친 기본 컬 라이브러리를 사용하기 때문입니다. 모든 종류의 프록시, 리디렉션과 완벽하게 작동하며 약속 및 스트림 인터페이스가 있습니다.

조그마한 요청 (>1mio 주간 다운로드)

요청에 대한 드롭인 교체이지만 훨씬 더 작고 옵션도 적습니다. 후드 아래에서 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-unfetch에 의해 처리된다"고 나와 있으므로 둘의 조합을 보고해야 합니다.
• isomorphic-unfetch 는 Node.js용 node-fetch( code , docs )를 사용하므로 보고된 크기는 최소한 node-fetch의 크기여야 합니다(이전 주석 참조).

그것이 너무 많이 제기되었으므로 node-fetch 에 대한 나의 경험에 대해 약간 말해야 합니다.

우선 상당한 성과입니다. 여기에 들어간 코드와 엔지니어링 노력의 양은 우리가 요청한 것보다 훨씬 많습니다. fetch 는 작은 API처럼 보이고 사람들은 Node.js에서 호환 가능한 API를 제공하려는 노력이 명목이라고 생각하지만 실제로는 그렇지 않습니다.

결과적으로 코드 기반은 방대합니다. 브라우저 번들에서는 전혀 볼 수 없는 Node.js의 상당한 종속성이지만 종속성 크기가 Node.js, 특히 서버리스 환경에서 문제가 되지 않는 것은 아닙니다.

node-fetch 는 브라우저의 API를 완전히 에뮬레이트하는 모든 작업을 수행하기 때문에 테스트할 때 필수 불가결하지만 응용 프로그램에서 사용하는 경우 Node.js 및 브라우저에서 실행되는 응용 프로그램에서도 그만한 가치가 있는 너무 많은 코드와 너무 많은 간접 참조.

IMO, 현재 Node.js와 브라우저 모두에서 http 클라이언트가 되고자 하는 라이브러리에 대한 올바른 접근 방식은 브라우저에서 fetch 및 require(‘http’) 를 사용하여 분할 구현으로 균일한 API를 구현하는 것입니다. Node.js의 fetch 또는 require(‘http’) 를 직접 대상으로 해서는 안 되며 양쪽에서 이러한 API를 에뮬레이트하는 데 의존해서는 안 됩니다. 이것은 믿을 수 없을 정도로 작은 bent 구현에서 볼 수 있듯이 실제로 생각하는 것보다 훨씬 쉽습니다. https://github.com/mikeal/bent/tree/master/src

@mikeal 제곱하기 힘들어요

결과적으로 코드 기반은 방대합니다. 브라우저 번들에서는 전혀 볼 수 없는 Node.js의 상당한 종속성이지만 종속성 크기가 Node.js, 특히 서버리스 환경에서 문제가 되지 않는 것은 아닙니다.

OP에 나열된 0.4kB 번들 크기와 함께 제공된 모든 대안 중 가장 작은 것은 무엇입니까?

@domenic 브라우저 API를 에뮬레이트하는 복잡성이 주요 문제이며 디버그를 시도할 때 불필요한 코드와 간접 참조가 많습니다. Blob API 가 있고 body header marshalling 의 거의 400행이 있으며 이는 보고 있지도 않습니다. 노출되는 실제 API.

내가 말했듯 이 그것은 인상적이지만 fetch API를 에뮬레이트하는 것 외에 다른 작업을 수행하려는 경우 매우 간결하고 영리하며 궁극적으로 불필요한 코드입니다.

@mikeal 당신은 node-fetch가 fetch API와 100% 호환되기 위해 더 많은 코드가 필요하다고 언급조차 하지 않았습니다: what-wg(환경을 에뮬레이션할 때 필요한 것)에서 읽고 쓸 수 있는 스트림을 지원하지 않습니다. Cloudflare 작업자처럼.

흠, 나는 여전히 "0.4 kB, 테이블의 다른 모든 항목보다 작고 구부러진 크기의 0.25x"로 "궁극적으로 불필요한" 코드의 "톤"을 제곱하는 방법을 이해하지 못합니다(아마도 "오른쪽 접근" 및 "믿을 수 없을 정도로 작음").

@domenic 브라우저 번들 크기를 비교하고 있습니까? Node.js에서 디버깅하는 복잡성에 대해 이야기하고 있습니다. 브라우저에서는 대부분의 node-fetch 코드가 존재하지 않을 것으로 예상하므로 무엇을 비교하고 있는지 잘 모르겠습니다.

OP의 값을 비교하고 있습니다. 어떻게 측정되는지 잘 모르겠습니다. 아마도 올바르게 측정되지 않았을 수 있습니다. 이는 OP를 업데이트하는 데 좋은 정보가 될 것입니다!

@domenic 아 예, 이것들은 모두 브라우저 번들 크기이며, 게시물이 꽤 오래되었기 때문에 bent 수치가 여전히 충분히 비슷하지만 많은 것들이 최신이 아닐 수 있습니다.

@root/request - 500 LoC 및 ZERO 종속성으로 작성된 80/20 드롭인 교체:

의도적으로 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 를 사용할 수 있으며 앞으로 수십 년 동안 계속 사용할 수 있습니다. 하지만 deprecation이 사용되어야 하는 것은 아닙니다. 지원 중단은 누군가가 플러그를 뽑기로 결정할 때까지 사람들이 자신의 코드를 업그레이드할 수 있는 "유예 기간"으로 행동을 촉구하는 역할을 해야 합니다.

저는 "지원 중단"이 "지원 종료" 또는 "유지 관리 종료"를 표시하는 데 사용되는 것을 정말 싫어합니다. 그러나 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);

처음부터 TS로 작성된 것을 감안할 때 최신 유형 스크립트 SPA를 구축하는 경우 Wretch 가 최상의 옵션이라는 것을 알았습니다. 사실상 Axios와 동일한 기능이며 추가 미들웨어 를 지원합니다. API도 Ky에 비해 몇 군데 더 좋은 것 같아요.

이들 중 어떤 것이 http2를 지원합니까?

@sakalys got 에는 실험적인 HTTP2 지원이 있으며, 이는 다음 주요 릴리스(곧 출시)에서 내장되어 안정적으로 제공될 예정입니다.

거의 드롭 인 교체?

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

이 라이브러리가 더 이상 사용되지 않는 것을 보니 정말 슬픕니다. 나는 axios를 좋아하지만 어떤 목적으로 적, 나의 첫 번째 선택은 요청이었습니다.

이러한 지원 요청 타이밍이 있습니까? 첫 번째 바이트까지의 시간, 네트워크 지연 등?
프로젝트에 요청 라이브러리를 사용하고 있으며 타이밍이 중요합니다.

Google은 gaxios를 제공합니다. https://github.com/googleapis/gaxios - 노드 가져오기를 통한 axios API

$ got readme에서 got , request , node-fetch , axios , superagent 를 잘 비교했습니다. : https://github.com/sindresorhus/got#comparison
_(부정확한 내용이 있으면 PR 환영합니다. 최대한 중립적으로 유지하려고 노력했습니다.)_

Got에는 request 에서 이동하기 위한 마이그레이션 가이드도 있습니다. https://github.com/sindresorhus/got/blob/master/migration-guides.md

request 에서 다음으로 이동하기 위한 Got의 마이그레이션 가이드가 _이동_했습니다.
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

우편 배달부 요청을 추가하도록 제안할 수 있습니까? 다음 프로젝트에서 이것을 시도할 것입니다. 어쨌든, 이것은 문서에 그것에 대해 말한 것입니다 ...

Postman Runtime 내에서 사용되는 우수한 요청 모듈의 포크입니다. 요청에서 수정되지 않은 몇 가지 버그수정이 포함되어 있습니다.

Redaxios는 기본 가져오기 https://github.com/developit/redaxios 를 사용하는 800바이트와 같습니다.

이런!! 나는 3시간 동안 내 코드를 계속해서 확인하면서 이것을 알아내고 있었다. 그리고 그것은 나에게 오류 404를 주었고, 나는 좌절했습니다. 정말 감사합니다. 나는 Fetch와 함께 갈 것이라고 생각합니다.

https://www.npmjs.com/package/teeny-request 는 Google API에서 사용하는 또 다른 옵션입니다.

요청과 비슷하지만 훨씬 작고 옵션도 적습니다. 후드 아래에서 노드 가져오기를 사용합니다. 요청을 사용할 위치에 팝니다. 모듈의 로드 및 구문 분석 시간을 개선합니다.

node-fetch 또는 현재 PostMan에서 유지 관리하는 requests 의 분기 버전이 더 낫습니다. 저는 이제 막 Node 여정을 시작했기 때문에 간단한 것이 필요합니다.

axios의 시간 초과는 수정되지 않는 것 같습니다👎🏿

여기서 핀이 보이지 않아 매우 놀랐습니다.

https://github.com/etherent/phin

url-request 는 어떻습니까?

https://github.com/Debdut/Url

url-request 는 어떻습니까?

https://github.com/Debdut/Url

아직 약간 어리고(1일!) 일부 기능이 부족하지만 유망해 보입니다.

@cjk 피드백 감사합니다. 어떤 기능이 마음에 드시나요? 좀 더 구체적으로 말씀해 주신다면.

빠른 Q. 기본 nodejs http 대신 이러한 라이브러리를 사용하면 어떤 이점이 있습니까?

@cgarrovillo 작은 코드 => 더 많은 영향

url-request 를 시도하고 기능 세트와 가능성을 살펴보세요 🤟

@cjk 피드백 감사합니다. 어떤 기능이 마음에 드시나요? 좀 더 구체적으로 말씀해 주신다면.

@Debdut 다음과 같은 기능을 생각하고 있습니다.

1. 입증
2. HTTP2
3. 프록시 지원
4. 압축
5. 시간 초과 처리
6. 사용자 정의 후크
7. 요청 취소

url-request 문서에서 지원되는 항목과 방법이 명확하지 않습니다.

그러나 나는 당신이 제공하는 많은 예를 좋아했습니다!

작동이 중지될 때까지 요청을 계속 사용하세요.

Angular rxjs에서 관찰 가능하고 우수합니다.

모든 라이브러리에 요청과 같은 쿠키 항아리가 있습니까?

테스트 노드가 빨간색인 HTTP 라이브러리를 얻었습니다. ✋

• npm 설치
• 컨텍스트에 추가됨
• 이제 흐름 편집기에서 내 js 함수에서 _got_을 가져왔습니다.

결과
HTTP 요청을 수행할 때 잘 작동합니다. (단일 테스트를 했다).
HTTPS 요청을 할 때 실패 ❌ . 나는 얻었다 :
RequestError: connect ECONNREFUSED 127.0.0.1:443

처음에는 이것이 node-red env와 관련된 것이라고 생각했습니다. 나중에 이것이 got repo: https://github.com/sindresorhus/got/issues/1414 의 공개 문제임을 발견했습니다. 👎
그리고 제 생각에는 _axios_ 대신 사용할 이유가 충분합니다. ✅
단지 당신이 알고 싶었습니다.

@damdauvaotran 모든 라이브러리에 요청과 같은 쿠키 항아리가 있습니까?

마이그레이션 가이드 got.js를 참조하세요.

gaxios 가 언급되지 않은 이유는 무엇입니까?

FWIW, 여기에 맨 위에 언급된 모든 프로젝트를 비교하는 NPM 동향 링크 가 있습니다. 결정에 관련된 유일한 요소는 아니지만 인기도는 우리와 대부분의 프로젝트에서 매우 중요합니다.
이 글을 쓰는 시점에서 node-fetch 가 가장 인기 있는 대안입니다.

흥미로운 @ericsnap ... node-fetch 및 axios는 각각 인기 1위와 3위(거의 2위)입니다.

그리고 나는 gaxios 문서 에서 다음 스트랩라인을 주목합니다.

node-fetch 위에 인터페이스와 같은 axios를 제공하는 HTTP 요청 클라이언트

따라서 gaxios는 가장 인기 있는 두 라이브러리를 결합합니다. 나는 gaxios로 전환해 왔으며 사용하는 것이 매우 재미있습니다.

노드 가져오기 / axios

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

현재 요청 대안을 검토한 후 @sindresorhus 에 뛰어들었습니다. API에 익숙해지는 데 하루 정도 걸렸습니다(문서는 상당히 좋았습니다). extend 로 인해 LoC가 크게 감소하고 한 곳에서 너무 많은 것을 설정하면 호출 사이트 및 오류 처리는 일반적으로 소수의 LoC에 불과합니다. 요청, 요청-약속, 요청-약속 네이티브 댄스보다 훨씬 매끄럽게 느껴집니다. 훌륭한 기능 세트도 있습니다. @sindresorhus 정말 감사합니다!

마이그레이션을 기대하지 않았지만 지금은 훨씬 깨끗해졌습니다.