지식 베이스

타입이 지정된 SDK

TypeScript 클라이언트가 먼저이고, 나머지는 그다음입니다.

세부 사항

npm에 게시되어 실제로 사용되고 있습니다. @openemail/sdk는 의존성이 없는 완전한 TypeScript 클라이언트로 ESM과 CommonJS 양쪽으로 게시되며, API가 제공하는 문서화된 모든 작업마다 메서드가 하나씩 있고, 클라이언트 생성기가 필요로 하는 인증 없는 메타 엔드포인트 두 개도 포함합니다. 키는 OPENEMAIL_API_KEY에서 읽고, 시도당 30초 타임아웃과 두 번의 재시도를 두며, 여러 워크스페이스를 다루는 프로세스를 위해 호출마다 apiKey를 덮어쓸 수 있고, 커서 루프를 직접 작성하지 않고도 목록을 넘길 수 있는 emails.iterate()를 제공합니다. Node 18 이상, Workers, Deno, Bun, 브라우저에서 동작합니다. 접두사가 잘못된 키는 첫 호출에서 401이 나는 대신 생성 시점에 예외를 던집니다. 이 검사는 접두사만 볼 뿐이므로, 형식은 올바르지만 철회된 키는 여전히 통신 과정에서 실패합니다.
SDK는 빌드할 때마다 OpenAPI 문서를 읽어 둘이 어긋나면 실패하는 정합성 검사로 서버에 묶여 있습니다. 스펙에 없는 작업을 가리키는 메서드, 메서드가 없는 문서화된 작업, 작업이 요구하는 것과 일치하지 않는 스코프 목록, 메서드는 있으나 레퍼런스에 항목이 없는 네임스페이스, 자체 매니페스트가 명시한 요청을 보내지 않는 메서드가 그 대상입니다. 검사는 무엇을 증명했는지 출력하며, 현재는 문서화된 104개 작업 전부를 다루는 116개의 SDK 메서드라고 표시됩니다. 그 옆에는 생성기 스크립트 두 개가 있어, 분류되지 않았거나 em dash로 작성된 작업은 출력하지 않습니다. 그래서 이 클라이언트는 나중에 덧붙여 작성한 래퍼가 아닙니다. API보다 한 릴리스 뒤처질 수 없습니다.
빠진 것은 릴리스 배관입니다. 패키지는 npm에 있으므로 bun add @openemail/sdk는 동작하지만, 릴리스 워크플로가 없습니다. 게시는 프리플라이트와 빌드, bun publish를 수동으로 실행하는 일이며, 따라서 새 버전은 변경이 반영될 때가 아니라 누군가 기억해 낼 때 npm에 올라갑니다. 기본으로 사용하는 API는 켜져 있고 응답합니다.
언어는 TypeScript 하나뿐이며, 나머지 언어에 대해서는 제각기 다른 속도로 뒤처지는 손으로 작성한 클라이언트 다섯 개 대신 OpenAPI 문서를 답으로 삼기로 의도적으로 정했습니다. 저장소에는 Python, Go, Ruby 클라이언트가 없고, 이 문서를 바탕으로 생성하는 체계가 갖춰지기 전에는 만들지 않을 것입니다.