개발자 도구 · JSON 포맷터 및 유효성 검사기
JSON이 웹 API의 기본 형식으로 XML을 대체한 방법
· 배경
JSON 표준 검증
20년 전에는 XML가 시스템 간에 전송되는 모든 항목에 대해 가정된 형식이었습니다. 이 게시물에서는 JSON이 웹 API에서 이를 어떻게 대체했는지, 각 형식의 설계 목적, XML이 여전히 일부 도메인을 지배하는 이유를 추적합니다.
SOAP 엔드포인트 1개 남음
하나의 SOAP 엔드포인트가 남습니다. 다른 모든 것이 JSON을 말하는 코드베이스에서 XML을 말하는 통합과 우리가 어떻게 여기까지 왔는지에 대한 질문입니다. 대조는 종종 클라이언트 코드에 나타납니다. 하나의 경로는 봉투, 네임스페이스 및 생성된 유형을 관리하는 반면, 최신 엔드포인트는 경량 HTTP 라이브러리를 통해 일반 개체를 교환합니다. 그 관찰은 보편적인 연대기가 아닌 지역적 구조를 설명합니다.
포맷터는 JSON만 처리합니다. 교차 형식 변환은 별도의 구문 변환기 패널에 속합니다. JSON의 인기로 인해 XML이 쓸모 없게 되지도 않으며 로컬 예쁜 인쇄가 API 계약을 검증하지도 않습니다. 이 문서에서는 이 경로에서 구현된 더 좁은 범위의 동작과 역사적 채택을 구별합니다. 결정적인 날짜, 원인 또는 시장 전반의 교체에 대한 뒷받침되지 않는 역사적 주장은 현재의 불이행에서 추론되기보다는 의도적으로 생략되거나 수정됩니다.
XML의 목적
XML의 목적은 콘텐츠, 네임스페이스, 스키마 및 변환 파이프라인이 혼합된 문서입니다. 요소는 텍스트와 하위 마크업을 모두 포함할 수 있고, 속성은 메타데이터를 전달할 수 있으며, 네임스페이스 한정 이름을 통해 어휘가 공존할 수 있습니다. XML 스키마, XPath 및 XSLT와 같은 기술은 문서 중심 워크플로 전반에 걸쳐 유효성 검사, 쿼리 및 변환을 지원합니다.
페이로드가 출판물, 서명된 비즈니스 문서 또는 확장 가능한 업계 메시지인 경우 이러한 기능은 불필요한 것이 아닙니다. 이는 단순한 객체와 배열 교환에 필요한 것보다 더 많은 개념을 부과합니다. 따라서 동일한 예제를 비교할 때는 문자 수뿐만 아니라 계약도 고려해야 합니다. XML 및 JSON은 서로 다른 모델링 도구를 노출하며 두 구문 모두 자동으로 올바른 도메인 의미를 제공하지 않습니다.
브라우저가 기본적으로 수행할 수 있는 작업
브라우저가 기본적으로 수행할 수 있는 작업 — XMLHttpRequest는 텍스트 형식을 검색할 수 있으며 브라우저는 XML DOM 구문 분석을 제공했습니다. 초기 JavaScript 코드는 때때로 JSON과 같은 텍스트를 평가했는데, 이는 입력을 신뢰할 수 없을 때 안전하지 않은 관행이었습니다. 표준화된 `JSON.parse`는 나중에 전용 파서를 제공했습니다. 구문 분석된 JSON은 자연스럽게 JavaScript 배열, 개체, 문자열, 숫자, 부울 및 null에 매핑됩니다.
이러한 매핑으로 인해 많은 브라우저 애플리케이션의 의식이 줄어들었지만 브라우저가 XML을 처리할 수 없었다거나 하나의 API만으로 채택이 결정되었다는 증거는 아닙니다. XML DOM은 자동으로 일반 객체가 되는 대신 요소, 속성 및 네임스페이스를 보존합니다. 인과관계에 대한 역사적 주장은 구현 편의성 이상의 소스가 필요하므로 여기서 지원되지 않는 버전은 생략하거나 수정합니다.
전환점 — XML과 함께 JSON을 제공한 다음 JSON만 제공하고 대부분의 새로운 서비스에 대해 SOAP를 대체하는 REST를 제공하는 공개 웹 API
전환점 - 많은 공개 웹 API가 XML과 함께 JSON을 노출했으며 이후의 많은 서비스에서는 JSON를 기본 표현으로 선택했습니다. SOAP가 확립된 생태계에 남아 있는 동안 경량 HTTP 스타일도 애플리케이션 API에 일반화되었습니다. 정확한 시장 점유율, 최초 이동자 및 날짜는 소스에 따라 다르며 이 포맷터 저장소에서 설정할 수 없습니다.
따라서 뒷받침되지 않는 역사적 주장은 깔끔한 단일 원인 이야기로 전환되기보다는 생략되거나 수정됩니다. 방어할 수 있는 메커니즘은 상호 운용성 압박입니다. 클라이언트 라이브러리, 문서, 도구 및 인접 서비스는 팀이 표준화하면 형식을 강화합니다. 해당 피드백은 XML이 사라졌거나 모든 REST API가 JSON을 사용한다고 주장하지 않고도 로컬 기본값을 설명할 수 있습니다.
스위치 비용
전환 비용 — JSON에는 특성과 하위 요소 간의 기본 구별이 없으며 혼합 콘텐츠 모델 및 주석 구문이 없습니다. 기본 JSON 문법은 애플리케이션 스키마도 정의하지 않습니다. 계약이 필요한 팀은 JSON 스키마 또는 OpenAPI와 같은 별도의 시스템을 추가하며, 각각 고유한 어휘, 도구 및 버전 관리 결정이 있습니다.
따라서 매핑을 명시적으로 설계하지 않으면 변환 정보가 손실될 수 있습니다. 반복되는 XML 요소는 배열이 될 수 있고, 네임스페이스 한정 이름에는 표현이 필요하며, 마크업과 함께 인터리브된 텍스트는 항상 깔끔하게 단순한 객체가 될 수는 없습니다. 더 간단한 페이로드 구문은 일부 복잡성을 외부 계약이나 규칙으로 이동시킵니다. 검증, 진화, 문서화가 불필요한 것은 아닙니다.
XML이 여전히 승리하는 경우
XML이 여전히 승리하는 경우 — 게시 워크플로는 혼합 콘텐츠와 확립된 문서 어휘의 이점을 누리고 Office 형식은 풍부한 문서를 표현하기 위해 XML 부분을 패키지합니다. 성숙한 재무 및 기업 메시징 표준은 네임스페이스, 스키마, 서명 또는 장기적인 도구 투자에 의존할 수 있습니다. 구문을 대체하려면 더 짧은 샘플 페이로드뿐만 아니라 생태계 조정도 필요합니다.
XML은 변환과 경로 기반 쿼리가 워크플로의 핵심인 경우에도 유용합니다. JSON은 XML이 일반 API를 제공할 수 있는 것처럼 추가 규칙을 사용하여 이러한 도메인을 제공할 수 있지만 마이그레이션 가치는 계약 및 도구 비용을 초과해야 합니다. 브라우저 연결 서비스의 인기가 모든 표현 문제에 대한 우월성을 증명하는 것은 아니며, 전체 대체에 대한 지원되지 않는 주장은 수정되거나 생략됩니다.
여기서 다루지 않는 내용
여기서 다루지 않는 내용 - 서로 다른 용어로 경쟁하는 프로토콜 버퍼 및 MessagePack과 같은 바이너리 대안입니다. 와이어 크기, 스키마 요구 사항, 스트리밍 동작 및 도구는 별도의 평가가 필요합니다. 이는 하이퍼미디어 규칙, 전송 프로토콜 또는 API 스타일을 비교하지도 않습니다. SOAP 대 REST는 단순히 XML 대 JSON이 아니며 두 표현 모두 HTTP를 통해 이동할 수 있습니다.
이는 또한 API 채택에 대한 정량적 출처의 기록이 아닙니다. 날짜, 비율, 최초 구현 또는 업계 전반의 원인에 대한 정확한 설명은 나열된 저장소 증거에 의해 뒷받침되지 않으므로 생략되거나 수정됩니다. 대신 이 기사는 완전한 역사적 서술의 증거로 결과를 제시하지 않고 관찰 가능한 형식 기능과 그럴듯한 엔지니어링 결과를 설명합니다.
요점: JSON는 완전성이 아닌 단순함으로 승리했습니다.
요점: JSON은 XML이 제공하는 모든 기능을 포함하고 있기 때문이 아니라 컴팩트 데이터 모델, 주류 언어의 직접 지원 및 광범위한 주변 도구를 통해 많은 웹 API에 대한 공통 기본값이 되었습니다. XML는 문서 구조, 네임스페이스, 변환 또는 확립된 스키마가 중심인 경우에 적합합니다. 형식 선택은 보편적 순위가 아닌 계약 및 생태계를 따릅니다.
ToolAcre는 이 경로에서 JSON을 구문 분석, 검증 및 인쇄하여 JSON의 좁은 모델을 반영합니다. API 의미를 인증하거나 XML를 더 이상 사용하지 않게 만들지 않습니다. 정의된 매핑이 필수 정보를 보존하는 경우에만 교차 형식 변환을 사용하십시오. 역사를 똑같이 조심스럽게 유지하십시오. 단일 전환점 또는 완전한 교체에 대한 뒷받침되지 않는 주장은 생략되거나 수정되어 방어할 수 있는 메커니즘과 현재 동작이 남습니다.