API용 JSON을 축소하는 방법 - 더 작은 페이로드, 더 빠른 응답

API 응답의 모든 바이트는 직렬화되어 네트워크를 통해 푸시되고 다른 쪽 끝에서 다시 구문 분석되어야 합니다. JSON을 축소하면 사람이 쉽게 읽을 수 있도록 공백, 탭, 줄 바꿈을 제거하여 단일 값을 건드리지 않고도 해당 페이로드가 축소됩니다. 트래픽이 많은 REST 및 GraphQL 엔드포인트, 연결이 느린 모바일 클라이언트, 원시 JSON으로 저장하는 모든 항목의 경우 저장된 바이트가 합산됩니다. 이 가이드에서는 실제 이전/이후 바이트 수를 사용하여 JSON을 축소하는 이유와 방법, 그렇게 하면 안 되는 경우, JavaScript 및 Python에서 축소하는 방법을 보여줍니다.

API용 JSON을 축소하는 이유는 무엇입니까?

축소는 기계에 필요하지 않은 문자, 즉 개행, 들여쓰기, 편집자가 가독성을 위해 추가하는 각 콜론과 쉼표 뒤의 공백을 대상으로 합니다. 이를 제거하면 API에 대한 몇 가지 구체적인 이점이 있습니다.

• 더 작은 페이로드: 모든 요청 및 응답에 대해 전송할 바이트 수가 더 적습니다. 이는 대용량 엔드포인트 및 계량형 모바일 데이터에서 가장 중요합니다.
• 더 빠른 전송 및 구문 분석: 네트워크를 통해 이동하는 데이터가 적고 클라이언트가 JSON을 읽을 때 스캔해야 하는 텍스트가 적습니다.
• 스토리지 및 로그 비용 절감: 데이터베이스 열, 캐시, 메시지 큐 또는 로그 라인에 보관된 JSON은 축소되면 공간을 덜 차지합니다.
• 깔끔한 와이어 형식: 클라이언트 애플리케이션에는 예쁜 인쇄가 필요하지 않습니다. 들여쓰기는 개발자 편의를 위한 것이지 앱이 의존하는 것이 아닙니다.

이전과 이후: 실제 바이트 비교

다음은 대부분의 편집기와 JSON.stringify(obj, null, 2)가 생성하는 2칸 들여쓰기 형식의 일반적인 REST 엔드포인트의 작은 사용자 레코드입니다. 모든 줄에는 개행 문자와 들여쓰기가 추가됩니다.

• {
• "ID": 42,
• "name": "에이다 러브레이스",
• "이메일": "ada@example.com",
• "활성": 사실,
• "역할": [
• "관리자",
• "편집자"
• ]
• }

해당 형식의 버전은 132바이트입니다. 축소하면 똑같은 데이터가 한 줄로 축소됩니다.

이는 하나의 작은 객체에서 34바이트(약 26%)가 절약된 것입니다. 실제 API 응답은 일반적으로 훨씬 더 크고 더 깊이 중첩되어 있습니다. 즉, 각각 동일한 키와 들여쓰기를 반복하는 수백 개의 레코드 배열입니다. 이러한 페이로드에서 축소는 일반적으로 원시 크기의 20~50%를 줄이고 모든 중첩 수준에서 절감 효과가 커집니다.

gzip과 Brotli는 어떻습니까?

대부분의 서버는 이미 gzip 또는 Brotli를 사용하여 응답을 압축하고 있으며 이러한 알고리즘은 반복되는 공백을 압축하는 데 매우 능숙합니다. 따라서 축소만으로 인한 유선 절감 효과는 원시 바이트 차이에서 알 수 있는 것보다 작습니다. 축소는 여전히 도움이 됩니다. 메모리, 캐시, 로그 및 스토리지에 있는 압축되지 않은 크기를 줄이고, 압축기가 수행할 작업을 줄이며, 압축을 사용할 수 없는 경우에도 더 작은 페이로드를 보장합니다. 둘 다 사용하십시오. 먼저 축소한 다음 서버를 압축하십시오.

JSON을 축소하지 말아야 할 경우

축소된 JSON은 읽기가 불편하므로 사람이 볼 필요가 있을 때마다 공백을 유지하십시오.

• 디버깅 및 개발: 예쁘게 인쇄된 JSON은 편집기, 직접 읽은 로그, 적극적으로 검사하는 응답에서 스캔하기가 훨씬 쉽습니다.
• 버전 제어의 구성 파일: package.json, tsconfig.json 및 유사한 파일은 diff를 읽을 수 있고 병합 충돌을 관리할 수 있도록 형식을 유지해야 합니다.
• 문서 및 예: API 문서의 샘플 요청 및 응답은 독자가 구조를 따를 수 있도록 형식을 지정해야 합니다.
• 사람이 직접 편집하는 모든 항목: 직접 관리하는 JSON은 들여쓰기를 유지해야 합니다. 빌드 또는 배포 단계로만 축소하세요.

코드에서 JSON을 축소하는 방법

자바스크립트/Node.js

JSON.stringify는 기본적으로 모든 선택적 공백을 생략하므로 공백 없이 문자열을 구문 분석하고 다시 문자열화하면 JSON.stringify(JSON.parse(input))라는 축소된 출력이 제공됩니다. 이미 객체가 있는 경우 JSON.stringify(obj)를 호출하면 됩니다. JSON.stringify(obj, null, 2)와 같은 세 번째 인수를 전달하면 그 반대가 되어 예쁘게 인쇄됩니다.

파이썬

Python의 json.dumps는 기본적으로 모든 쉼표와 콜론 뒤에 공백을 추가하므로 출력이 완전히 축소되지 않습니다. 압축 구분 기호를 전달하여 제거합니다: json.dumps(obj, 구분 기호=(",", ":")). 대신 예쁘게 인쇄하려면 json.dumps(obj, indent=2)를 사용하세요.

두 접근 방식 모두 데이터를 작성하기 전에 구문 분석하므로 유효성도 검증됩니다. 잘못된 형식의 JSON은 데이터를 제공하기 전에 오류를 발생시킵니다. 이것이 바로 스크립트를 작성하지 않고도 온라인 축소기가 브라우저에서 수행하는 작업입니다.

자주 묻는 질문

JSON을 축소하면 데이터가 변경되나요?

아니요. 축소는 토큰 사이의 공백만 제거합니다. 키, 값, 배열 및 객체는 그대로 유지됩니다. 파서는 {"a": 1} 및 {"a":1}을 정확히 동일한 객체로 읽으므로 축소된 JSON은 전송, 저장 및 구문 분석에 항상 안전합니다.

축소된 JSON은 얼마나 작나요?

이는 원본에 공백이 얼마나 있고 중첩되어 있는지에 따라 다릅니다. 컴팩트한 객체는 10~20% 줄어들 수 있지만 심하게 들여쓰기되고 깊게 중첩된 페이로드는 30~50% 줄어들 수 있습니다. 서버의 gzip 또는 Brotli 압축은 이미 반복되는 공백을 잘 처리하므로 전송상의 차이를 줄여준다는 점을 명심하세요.

API 응답에서 JSON을 축소해야 합니까?

프로덕션 트래픽의 경우 예 - 서식 지정에 신경 쓰지 않는 클라이언트 애플리케이션에 보기 좋게 인쇄된 JSON을 보낼 이유가 없으며 많은 프레임워크는 기본적으로 압축 JSON을 반환합니다. API를 직접 탐색하는 개발자를 위해 형식화된 옵션을 제공하는 것은 여전히 ​​좋은 일입니다. 일부 API는 ?pretty=true 플래그를 통해 노출합니다.

축소된 JSON이 여전히 유효한 JSON인가요?

완전히. 토큰 사이의 공백은 JSON 사양에서 선택 사항이므로 이를 제거하면 모든 호환 파서가 허용하는 유효한 JSON이 생성됩니다. 당신이 잃는 유일한 것은 인간의 가독성이며, 언제든지 다시 포맷하여 복원할 수 있습니다.

JSON 축소와 압축의 차이점은 무엇입니까?

축소는 유효하고 읽기 쉬운 JSON을 유지하면서 텍스트에서 선택적 공백을 제거합니다. 압축(gzip 또는 Brotli)은 클라이언트가 사용하기 전에 압축을 풀어야 하는 더 작은 바이너리 blob을 생성하는 알고리즘을 통해 바이트를 실행합니다. 그들은 서로 다른 레이어에서 작동하며 가장 잘 결합됩니다. 텍스트를 축소한 다음 전송 중에 압축합니다.