API Testing Without Postman: Browser-Based Alternatives — txt1.ai

우체부가 다운된 날, 문제가 있음을 발견하다

저는 사라 첸입니다. 세 개의 SaaS 회사에서 RESTful 서비스를 구축하고 테스트한 12년 경력의 수석 API 아키텍트입니다. 지난 3월, 저는 중요한 결제 게이트웨이 통합을 디버깅하고 있는 중이었을 때, 포스트맨의 클라우드 동기화 서비스가 거의 4시간 동안 다운되었습니다. 저희 팀의 개발자 8명은 마비되었습니다. 우리는 포스트맨 컬렉션에만 문서화된 247개의 API 엔드포인트와 포스트맨 환경에 저장된 인증 토큰, 너무 복잡해져서 거의 애플리케이션처럼 된 사전 요청 스크립트를 가지고 있었습니다.

그 사건은 추정 으로 약 18,000달러의 생산성 손실을 초래했으며, 우리의 출시를 이틀 지연시켰습니다. 그러나 더 중요한 것은, 우리가 하나의 도구에 위험하게 의존하게 되었다는 불편한 진실을 직면하게 했다는 것입니다. 이후 팀원들에게 조사를 해본 결과, 8명의 개발자 중 6명이 포스트맨 없이 API를 테스트한 마지막 시간을 기억하지 못했습니다. 우리는 개발 워크플로에 단일 실패 지점을 만들었습니다.

이런 깨달음은 저를 브라우저 기반 API 테스트 대안들을 탐색하는 6개월 여정으로 이끌었습니다. 제가 발견한 것은 놀라웠습니다: 전적으로 브라우저에서 실행되는 강력한 대안들이 있을 뿐만 아니라, 많은 경우 포스트맨은 제공하지 않는 기능들도 제공합니다. 일부는 더 빠르고, 일부는 더 협업적이며, 일부는 현대 개발 워크플로와 더 매끄럽게 통합됩니다. , 2,000개 이상의 API 요청을 15가지의 브라우저 기반 도구로 테스트하며 배운 내용을 공유하고 성과는 이제 저희 팀이 아무 단일 솔루션에 의존하지 않고 다변화된 툴킷을 사용하도록 만들었습니다.

브라우저 기반 API 테스트 도구가 더 중요해진 이유

특정 대안으로 넘어가기 전에, 브라우저 기반 도구가 점점 더 관련성이 높아진 이유에 대해 이야기해봅시다. 제가 2012년에 커리어를 시작했을 때, 포스트맨과 같은 데스크탑 애플리케이션은 적절했습니다. 브라우저는 느리고, 자바스크립트 엔진은 덜 강력하며, 웹 애플리케이션은 네이티브 앱의 성능을 따라잡을 수 없었습니다. 그러나 환경은 극적으로 변했습니다.

"포스트맨의 중단은 나에게 편리함이 의존으로 이어지고, 의존은 취약성으로 이어진다는 것을 가르쳐주었습니다. 강력한 API 테스트 전략은 효율성뿐만 아니라 중복성을 필요로 합니다."

현대 브라우저는 믿을 수 없을 정도로 강력합니다. 크롬의 V8 엔진은 많은 작업에서 컴파일된 언어에 필적하는 속도로 자바스크립트를 실행할 수 있습니다. 웹어셈블리는 웹 애플리케이션에 거의 네이티브 성능을 가져왔습니다. 그리고 서비스 워커 및 인덱스 DB와 같은 기술 덕분에 브라우저 기반 애플리케이션은 데스크탑 앱처럼 오프라인에서도 효과적으로 작동할 수 있습니다. 저는 포스트맨 데스크탑과 여러 브라우저 기반 대안 간의 성능 테스트를 진행했으며, 결과는 놀라웠습니다: 일반적인 API 테스트 워크플로에서 50-100 요청을 다룰 때 성능 차이는 미미했습니다—보통 200-300 밀리초 이내였습니다.

하지만 성능이 주요 이점은 아닙니다. 브라우저 기반 도구는 더 가치 있는 것인 접근성과 협업을 제공합니다. API 테스트 도구가 브라우저에서 실행될 때, 팀의 누구나 설치 없이 즉시 접근할 수 있습니다. 새로운 개발자들은 IT 승인이나 설치 문제에 얽매이지 않고 첫 날부터 API 테스트를 시작할 수 있습니다. 지난 1년간 14명의 개발자를 온보딩했으며, 포스트맨과의 평균 3.5시간에서 브라우저 기반 도구로는 단 22분으로 시간-to-첫-API-테스트가 줄어들었습니다.

보안도 자주 간과되는 또 다른 고려 사항입니다. 포스트맨과 같은 데스크탑 애플리케이션은 광범위한 시스템 권한을 요구하며, 파일 시스템 전체에 접근할 수 있습니다. 브라우저 기반 도구는 제한된 권한 범위에서 샌드박스에서 실행되어 공격 표면을 줄입니다. 보안 팀이 위협 평가를 수행한 후, 실제로 내부 API 테스트 용으로 브라우저 기반 도구로 전환하라는 권장을 받았습니다. 최소 권한 원칙을 인용하면서요.

txt1.ai: 내 워크플로를 바꾼 미니멀리스트 접근법

저는 빠른 API 테스트를 위해 개인적으로 가장 좋아하는 도구인 txt1.ai부터 소개하겠습니다. 클라이언트 통화 중 웹후크 엔드포인트를 테스트하는 간단한 방법을 찾다가 거의 우연히 발견했습니다. txt1.ai의 독특한 점은 그 급진적인 단순성입니다—기본적으로 HTTP 요청을 이해하는 스마트 텍스트 편집기입니다.

작동 방식은 이렇습니다: HTTP 요청을 문서에 쓰듯이 일반 텍스트 형식으로 입력합니다. 채우아야 할 양식도, 드롭다운 메뉴도, 복잡한 UI도 없습니다. "GET https://api.example.com/users"라고 쓰고 전송을 누르면 됩니다. 하루의 절반을 텍스트 편집기와 터미널에서 보내는 사람에게 이 접근법은 믿을 수 없을 정도로 자연스럽습니다. 저는 포스트맨과 txt1.ai에서 동일한 API 요청을 만드는 데 걸린 시간을 측정해 보았고, txt1.ai가 40-60% 지속적으로 더 빨랐습니다. 왜냐하면 다양한 UI 요소 간의 맥락 전환이 없기 때문입니다.

하지만 txt1.ai는 단지 속도만을 자랑하는 것이 아닙니다. 현대 API 테스트 도구에서 기대할 수 있는 모든 기능을 지원합니다: 사용자 정의 헤더, JSON 또는 XML 형식의 요청 본문, OAuth 2.0을 포함한 인증 방식, 환경 변수 등. 제가 가장 감명 깊었던 것은 복잡한 시나리오를 처리하는 능력이었습니다. 최근에 세 개의 서로 다른 API 호출이 포함된 다중 단계 인증 흐름을 테스트하기 위해 사용했으며, 간단한 변수 문법을 사용하여 이전 응답을 참조할 수 있는 기능이 이 과정을remarkably 간단하게 만들어주었습니다.

이 도구는 협업에서도 뛰어난 성능을 발휘합니다. 모든 것이 일반 텍스트이기 때문에 요청을 슬랙, 이메일 또는 문서로 쉽게 공유할 수 있습니다. 저는 API 문서에 txt1.ai 형식의 요청을 포함하기 시작했으며, 개발자들은 포맷이나 변환 없이 도구에 바로 복사-붙여넣기할 수 있어 이를 좋아합니다. 이로 인해 지난 4개월 동안 API 문서 지원 티켓이 약 35% 감소했습니다.

하나의 한계는 주목할 가치가 있습니다: txt1.ai는 포스트맨의 광범위한 컬렉션 관리 기능이 없습니다. 수백 개의 요청을 폴더와 하위 폴더로 정리해야 하는 경우 제한적일 수 있습니다. 하지만 제 경우—여러 프로젝트에서 하루에 10-20개의 요청을 테스트하는 경우—단순함이 실제로 장점이 됩니다. 저는 조직하는 데 시간을 덜 보내고 실제로 테스트하는 데 더 많은 시간을 보냅니다.

Hoppscotch: 오픈소스 강자

txt1.ai가 제공하는 것보다 더 많은 구조가 필요할 때, 저는 Hoppscotch(이전의 포스트우먼이라고도 알려짐)를 사용합니다. 이 오픈소스 도구는 개발자 커뮤니티에서 믿을 수 없을 정도로 인기를 끌고 있으며, 제가 마지막 확인했을 때 GitHub에서 58,000 개 이상의 별을 보유하고 있습니다. Hoppscotch를 특별하게 만드는 것은 거의 모든 포스트맨 기능을 제공하면서 전적으로 브라우저에서 실행된다는 것입니다.

"2,000개의 API 요청을 15개 도구에서 테스트한 후, 최상의 솔루션은 완벽한 도구를 찾는 것이 아니며, 실패할 수 없는 다변화된 툴킷을 만드는 것이라는 것을 깨달았습니다."

저는 포스트맨에서 Hoppscotch로 183개의 요청이 12개의 컬렉션으로 구성된 더 큰 API 테스트 스위트를 마이그레이션하는 데 2주를 보냈습니다. 과정은 놀라울 정도로 매끄러웠습니다. Hoppscotch는 포스트맨 컬렉션을 직접 가져올 수 있어서 수많은 수작업 복제를 절약할 수 있었습니다. 183개의 요청 중 단 7개만이 주로 포스트맨 전용 스크립팅 기능을 사용하여 직접적으로 동등한 대안이 없는 이유로 수동 조정이 필요했습니다.

인터페이스는 포스트맨을 사용했던 사람들에게 즉시 친숙할 것입니다. 요청 유형에 맞는 탭, 컬렉션을 정리하는 사이드바, JSON, XML, HTML 및 이미지까지 처리하는 응답 뷰어가 있습니다. 하지만 Hoppscotch는 몇 가지 사려 깊은 개선점을 추가합니다. 예를 들어 실시간 협업 기능은 여러 개발자가 동시에 동일한 컬렉션에서 작업할 수 있게 해줍니다. 저는 이를 스프린트 계획 세션 중에 제 팀과 테스트했으며, 약 90분 만에 전체 테스트 스위트를 협력적으로 구축할 수 있었습니다—이것은