개발자 도구 · JSON 포맷터 및 유효성 검사기
축소된 API 응답 읽기: 예쁜 인쇄가 눈을 가늘게 뜨는 것보다 나은 이유
· 그것이 중요한 이유
JSON 개발자 워크플로 검증
축소된 JSON는 컴퓨터용입니다. 이 게시물에서는 서버가 공백을 제거하는 이유, 한 줄에 대해 디버깅할 때 손실되는 사항, 형식 지정이 페이로드를 실제로 추론할 수 있는 것으로 바꾸는 방법에 대해 설명합니다.
한 줄에 30KB
한 줄에 30KB — 네트워크 패널의 응답 본문과 여기에서 찾을 수 없는 필드입니다. 검색을 통해 키를 찾을 수 있지만 상위 개체, 인접 레코드 또는 배열 경계에 대한 컨텍스트는 거의 제공되지 않습니다. 수평 스캐닝은 또한 반복되는 속성 이름을 구별할 수 없게 만듭니다. 이는 페이지가 매겨진 API 페이로드에서 흔히 발생합니다.
서식을 지정하면 문서가 구문 분석되고 다시 직렬화됩니다. 구조를 나타내지만 숫자 철자, 이스케이프 및 공백을 정규화할 수 있습니다. 패널은 또한 루트 유형, 키 또는 항목 수, 깊이 및 노드 수를 포함하는 모양 요약을 보고하므로 모양만 보는 것보다 결과를 더 쉽게 확인할 수 있습니다. 특히 큰 숫자, 지수 표기 및 이스케이프된 텍스트와 관련하여 어휘 충실도가 중요한 경우 원시 응답을 보존합니다.
서버가 축소되는 이유 — 대역폭, 압축 상호 작용 및 기본 직렬 변환기 설정, 그리고 그 중 어느 것도 독자에게 도움이 되지 않는 이유
서버가 축소되는 이유 - 대역폭, 압축 상호 작용 및 기본 직렬 변환기 설정, 그리고 그 중 어느 것도 독자에게 도움이 되지 않는 이유. 들여쓰기를 제거하면 압축되지 않은 바이트 수가 줄어들고 장식용 공백을 생성하는 CPU 소비를 방지할 수 있습니다. 범용 압축은 이미 반복되는 공간을 효율적으로 축소하므로 전송된 절감 효과는 원시 차이보다 작을 수 있지만 압축 출력은 여전히 기존 방식으로 유지됩니다.
기계는 시각적 정렬보다는 토큰을 소비하며 클라이언트는 일반적으로 본문을 즉시 데이터 구조로 구문 분석합니다. 하나의 응답을 조사하는 인간은 정반대의 요구 사항을 가지고 있습니다. 안정된 줄 바꿈과 들여쓰기는 소유권과 중첩을 드러냅니다. 사고 발생 시 캐싱, 응답 크기 또는 서버 동작을 변경할 수 있는 자세한 출력을 프로덕션 엔드포인트에 보내도록 요청하는 대신 진단을 위해 캡처된 복사본을 예쁘게 인쇄합니다.
포맷 후 표시되는 구조
서식 지정 후 표시되는 구조(중첩 깊이, 배열 길이, 빈 개체 및 끝에 숨어 있던 null)입니다. 들여쓰기는 `status`이 응답, 항목 또는 내장된 소유자에 속하는지 여부를 보여줍니다. 별도의 줄은 반복되는 레코드를 노출하고 구문 분석된 의미를 변경하지 않고 채워진 개체 중 하나의 `{}`을 시각적으로 명확하게 만듭니다.
모양 요약은 또 다른 검사를 제공합니다. 항목이 0개인 배열 루트는 빈 `items` 배열을 포함하는 개체와 다른 내용을 알려주는 반면, 최대 깊이는 예기치 않게 래핑된 결과를 노출할 수 있습니다. 서식을 지정하면 대괄호가 예상 컨테이너를 닫는지 여부도 명확해집니다. 관련 없는 분기를 축소하고 의심되는 값에 대한 경로를 계속 표시하려면 편집기에서 접기를 사용하세요.
실제 버그 발견
실제 버그 발견 — 숫자가 예상되는 문자열, 누락된 키 대 null 값, 단일 요소가 있는 배열. 예쁘게 인쇄하면 따옴표와 리터럴을 통해 유형을 읽을 수 있습니다. `"0"`, `0`, `false` 및 `null`는 급하게 검토하는 동안 압축 로그가 흐려질 수 있는 네 가지 값입니다.
구조는 또한 명시적인 공허함과 부재를 구별합니다. `nextCursor`이 누락되면 서버가 페이지 매김 메타데이터를 생략했음을 의미할 수 있으며 `"nextCursor":null`은 의도적으로 최종 페이지를 표시할 수 있습니다. 빈 `items` 배열은 클라이언트 대체 논리를 발생시키는 누락된 `items` 속성과 다릅니다. 형식을 지정하면 이러한 차이가 드러나지만 API 계약에 따라 어떤 형식이 올바른지 결정됩니다.
작업된 예: 페이지가 매겨진 응답
작업된 예: 페이지가 매겨진 응답 — 형식을 지정하고 다음 페이지 커서를 찾고 항목 배열이 비어 있음을 확인합니다. `{"items":[],"page":{"next":"abc","count":0}}`과 같은 압축 페이로드는 유효하지만 레코드가 없으면 커서와 개수가 충돌합니다. 들여쓰기는 결과 데이터와 별도로 페이지 매김 메타데이터를 그룹화합니다.
이 보기는 구체적인 질문을 제시합니다. 커서가 계산된 후 필터가 모든 항목을 제거했는지, `count` 페이지 로컬인지 전체인지, 빈 페이지에 대해 다음 커서가 존재해야 하는지 등입니다. 포맷터는 이에 응답할 수 없지만 불투명한 한 줄을 요청 매개변수 및 문서에 대해 확인할 수 있는 필드로 바꿉니다. 증거를 위해 원래 응답 및 상태 헤더를 보존합니다.
두 응답 비교
두 응답 비교 — 두 응답 모두 동일한 들여쓰기로 서식을 지정하여 텍스트 비교 패널에서 실제 차이점만 강조 표시합니다. 일관된 레이아웃은 하나의 페이로드의 컴팩트 직렬화가 들여쓰기된 복사본과 전체 문서 차이를 생성하는 것을 방지합니다. 읽을 수 없는 문자 스트림을 이동하는 대신 변경된 값, 삽입된 레코드 및 누락된 키가 현지화된 라인을 차지하도록 만듭니다.
결론을 내리기 전에 휘발성 필드를 제어하세요. 요청 ID, 타임스탬프, 서명 및 순서가 지정되지 않은 컬렉션은 비즈니스 데이터가 안정적인 경우에도 텍스트 비교를 지배할 수 있습니다. 멤버 순서가 유지해야 하는 증거인 경우 무심코 키를 정렬하지 말고 배열 순서가 데이터라는 점을 기억하세요. 주문이 계약과 관련이 없지만 직렬화가 다를 경우 구조 인식 비교가 바람직합니다.
여기서 다루지 않는 내용
여기서 다루지 않는 내용 — 압축되거나 인코딩된 본문을 디코딩하고 프로토콜 버퍼와 같은 바이너리 형식을 검사합니다. Base64, gzip 바이트 또는 암호화된 봉투로 표시된 본문은 먼저 콘텐츠 인코딩에 대한 지식을 바탕으로 디코딩되어야 합니다. 해당 문자를 JSON 구문 분석기에 입력하면 기본 메시지에 대해 아무 것도 알려주지 않는 구문 오류가 발생합니다.
또한 예쁜 인쇄는 OpenAPI 스키마의 유효성을 검사하거나, 서버 상태 코드를 설명하거나, 클라이언트 역직렬화가 동일한 유형을 사용한다는 것을 증명하지 않습니다. 손실이 있는 JavaScript 구문 분석 후에 잘린 네트워크 캡처를 복원하거나 정확한 숫자 토큰을 보존할 수 없습니다. 바이너리 페이로드에 대한 프로토콜별 도구를 사용하고 사람이 읽을 수 있는 렌더링과 함께 헤더, 요청 컨텍스트 및 원시 바이트를 유지합니다.
요점: 먼저 포맷한 다음 디버그하세요.
요점: 먼저 형식을 지정한 다음 디버그합니다. 이론을 형성하기 전에 형식 지정자의 들여쓰기 선택을 사용하여 페이로드의 계층 구조를 노출합니다. 관련 분기를 찾고, 값 유형을 확인하고, 누락, null 및 빈 상태를 구별합니다. 정상으로 알려진 샘플이 있는 경우 하나의 레이아웃에서 응답을 비교하고, 세부 정보 재직렬화를 위해 원시 입력을 유지하면 정규화될 수 있습니다.
읽기 가능 JSON은 시각적인 노력을 줄여줍니다. 이는 API 계약을 대체하지 않습니다. 의심스러운 필드가 표시된 후 페이지 매김 정의, 스키마 요구 사항, 상태 헤더 및 요청 매개변수를 확인하세요. ToolAcre는 브라우저에서 이러한 구문 분석 및 형식 지정을 수행하므로 제공된 문서는 ToolAcre 애플리케이션 서버에 게시되지 않지만 민감한 캡처는 정책에 따라 여전히 최소화되어야 합니다.