JSON이 매우 간단하고 다루기 쉬운데 왜 XML(SOAP)을 사용하는가?

JSON이 매우 간단하고 다루기 쉬운데 왜 XML(SOAP)을 사용하는가?

JSON을 사용한 데이터 송수신은 간단한 HTTP 요청으로 이루어집니다.반면 SOAP에서는 많은 것을 관리해야 합니다.XML을 해석하는 것도 어려울 수 있습니다.Facebook도 그래프 API에서 JSON을 사용하고 있다.왜 아직도 SOAP을 사용해야 하는지 궁금하네요.SOAP이 여전히 더 나은 옵션인 이유 또는 영역이 있습니까?(데이터 형식에도 불구하고)

또한 간단한 클라이언트-서버 애플리케이션(서버와 연결된 모바일 애플리케이션 등)에서 SOAP은 JSON보다 더 나은 이점을 제공할 수 있습니까?

JSON과 SOAP의 주요/중요한 차이점을 제시해 주시면 감사하겠습니다(있다면).

SOAP의 장점은 다음과 같습니다.

• 모두가 JSON을 사용하는 대신 SOAP을 사용하는 큰 이유가 하나 있습니다.JSON을 설정할 때마다 프로젝트별로 항상 독자적인 데이터 구조를 작성합니다.데이터가 어떻게 인코딩되고 전달되는지가 아니라 데이터 형식, 즉 데이터 모델이 어떻게 정의되는지를 의미합니다.
• SOAP에는 데이터가 특정 형식으로 지정되는 업계 성숙형 방법이 있습니다.예를 들어, 「카트는 제품의 집합이며, 각 제품은 이러한 속성을 가질 수 있습니다」 등입니다.WSDL 문서를 잘 정리하면 이 점이 확실히 드러납니다.「W3C 사양」을 참조해 주세요.웹 서비스 설명 언어
• JSON은 이 데이터 구조를 지정하는 방법은 비슷합니다(JavaScript 클래스가 가장 일반적인 방법이라고 생각됩니다). 그러나 JavaScript 클래스는 이러한 목적으로 사용되는 데이터 구조가 아닙니다.불가지론적이고 확립되어 널리 사용되고 있습니다.

즉, SOAP에는 WSDL(성숙한 형식의 문서)로 데이터 구조를 지정하는 방법이 있습니다.JSON에는 표준적인 방법이 없습니다.

클라이언트 애플리케이션을 작성하고 있으며 서버 구현이 SOAP을 사용하여 이루어지는 경우 클라이언트 측에서 SOAP을 사용해야 합니다.

또, 다음을 참조해 주세요.「ENTERPRISE」애플리케이션에서 SOAP over JSON 및 커스텀 데이터 형식을 사용하는 이유는 무엇입니까?

요즘 SOAP은 완전 과잉 살상이야, IMHO.사용할 수 있어서 좋았고, 배울 수 있어서 좋았고, 지금 JSON을 사용할 수 있는 것은 아름답습니다.

SOAP 서비스와 REST 서비스(JSON 사용 여부에 관계없이)의 유일한 차이점은 SOAP WS에는 항상 자체 WSDL 문서가 있으며, 이 문서는 REST 내에서 사용자가 직접 작성해야 한다는 것입니다(적어도 데이터 구조에 대한 문서).다음은 두 가지 모두에 대한 나의 반대 의견과 찬성입니다.

쉬다

장점

• 경량화(모든 수단: 서버 측 또는 클라이언트 측 확장 기능 불필요, XML의 큰 청크 전송 불필요)
• 데이터 포맷의 자유 선택 - 플레인 TXT, JSON, XML을 사용할지, 또는 독자적인 데이터 포맷을 작성할지는 사용자에게 달려 있습니다.
• 현재 대부분의 데이터 형식(XML을 사용하더라도)은 실제로 필요한 양의 데이터만 HTTP를 통해 전송되지만 SOAP에서는 5바이트의 데이터에 대해 1kB의 XML 정크(과장, Ofc, 단, 요점은 이해했습니다)가 필요합니다.

단점

• docblock 코멘트에서 문서를 생성할 수 있는 툴도 있습니다.좋은 문서를 작성하려면 이러한 코멘트를 매우 알기 쉽게 작성할 필요가 있습니다.

비누.

장점

• 에는 기본적인 docblock 코멘트에서 생성 가능한 WSDL이 있으며(많은 언어로 되어 있어도 코멘트가 없어도) 문서로서 기능하는 WSDL이 있습니다.
  • WSDL과 연동하여 이 요구 인터페이스를 강화시킬 수 있는 툴도 있습니다(REST를 위한 툴에 대해서는 모릅니다).
• 엄격한 데이터 구조

단점

• 엄격한 데이터 구조
• 데이터 전송에 XML(전용!)을 사용하는 한편, 각 요구에는 대량의 정크 데이터가 포함되어 응답에는 5배의 정크 정보가 포함되어 있습니다.
• 외부 라이브러리의 필요성(클라이언트 및/또는 서버의 경우, 오늘날에는 이미 많은 언어의 네이티브 부분이 있지만, 사람들은 항상 서드파티를 사용하는 경향이 있습니다.)

결론적으로, 저는 REST(및 JSON)보다 SOAP을 선호할 큰 이유가 없다고 생각합니다.둘 다 같은 기능을 할 수 있습니다.대부분의 일반적인 웹 프로그래밍 언어로 JSON 인코딩과 디코딩이 네이티브로 지원되고 있습니다.JSON을 사용하면 더 많은 자유를 얻을 수 있고 불필요한 정보 정크로부터 HTTP 전송을 제거할 수 있습니다.만약 API를 구축한다면 JSON과 함께 REST를 사용할 것입니다.

나는 여기서 보는 JSON의 동향에 대해 조금 동의하지 않는다.JSON은 주문하기 쉽지만, 꽤 제한적이라고 감히 말할 수 있습니다.예를 들어 SOAP WS는 마지막이 아닙니다.실제로 SOAP 클라이언트/서버 간에는 엔터프라이즈 서비스 버스, 암호 기반 인증 방식, 사용자 관리, 타임스탬프 요청/복제 등이 있습니다.이 모든 것을 위해 SOAP(Web 서비스)를 중심으로 서비스를 제공하고 XML에 내용을 삽입하는 대규모 소프트웨어 플랫폼이 있습니다.따라서 JSON은 소규모 프로젝트에서는 충분할 뿐만 아니라 전송 제어와 콘텐츠(즉, "Web 서비스")를 분리하면 상당히 제한적일 수 있습니다.컨텐츠, 즉 실제 서버를 개발하지만, 모든 전송은 다른 팀에 의해 관리되며, 한 팀이 인증하고 다른 팀이 배포합니다.)대기업에서의 제 경험이 관련이 있는지는 모르겠지만, JSON은 거기서 살아남지 못할 거라고 생각합니다.데이터 표현에 대한 기본적인 요구 외에도 제약이 너무 많습니다.따라서 문제는 JSON RPC 자체가 아니라 복잡한 애플리케이션에서 발생하는 복잡성을 관리하기 위한 추가 도구를 놓치는 것입니다(작업이 복잡하지 않다는 것은 말할 것도 없고 소프트웨어는 이를 생산하는 회사의 복잡성을 반영하고 있습니다).

이 스레드에는 기본적인 오보가 많은 것 같습니다.응답에 SOAP, REST, XML 및 JSON의 개념이 혼재되어 있는 것 같습니다.

여기 몇 가지 설명이 있습니다.

XML 및 JSON(기타)은 정보의 부호화입니다.SOAP은 통신 프로토콜 REST는 (아키텍처) 스타일입니다.

둘 이상의 것을 함께 사용할 수도 있지만 각각 다른 용도로 사용됩니다.

먼저 데이터 구조를 XML 대 JSON으로 인코딩합니다.

현재 JSON이 지원하는 모든 작업은 XML로 수행할 수 있지만, 그 반대는 할 수 없습니다.JSON은 최종적으로 XML의 모든 기능을 채택할 예정이지만, JSON의 제안자는 아직 모든 문제에 직면하지 않았습니다.경험이 쌓이면 그 차이를 메우기 위해 추가될 것입니다.예를 들어 JSON은 스키마 및 바이너리 형식으로 시작하지 않았습니다.

SOAP은 작업을 호출하기 위한 통신 프로토콜입니다.HTTP, SMTP 등 위에서 실행됩니다.다른 많은 기능 외에도 SOAP 메시지는 여러 "응용 프로그램" 계층 프로토콜에 걸쳐 있을 수 있습니다. 즉, SOAP 메시지를 서비스 엔드포인트에 HTTP로 전송하여 다른 시스템의 메시지 큐에 넣을 수 있습니다.SOAP은 분산 시스템의 다른 부분 간에 요청된 이동에 따른 인증, 메시지 인증 등의 유지 문제를 해결합니다.

JSON 및 기타 데이터 형식은 SOAP을 통해 전송할 수 있습니다.SOAP을 통해 바이너리 고정폭 부호화 객체를 전송하는 시스템을 사용하고 있습니다.그것은 문제가 되지 않습니다.

예를 들어 우체부만이 당신에게 편지를 보낼 수 있다면, 그것은 HTTP일 뿐이지만, 누군가 당신에게 편지를 보낼 수 있다면 당신은 SOAP를 원합니다.(즉, 메시지 전송 보안과 메시지 콘텐츠 보안)

6개의 REST 제약은 아키텍처 스타일입니다.흥미롭게도 REST의 처음 몇 년간은 SOAP에 예제가 있었습니다(REST나 SOAP 같은 것은 없습니다).

"헤비웨이트 비대함 등" SOA SOAP 시스템에는 단일 엔티티의 GET, PUT, POST 인스턴스 등의 작업을 수행하는 모노리스가 있을 수 있습니다.SOAP 에는 이러한 조작이 사전에 정의되어 있지 않지만, 통상은 그렇게 사용됩니다.

SSL/TLS 종단 프록시를 사용하여 HTTP에서만 "REST" 서비스를 구축한 경우 REST의 네 번째 제약 조건을 위반했을 수 있습니다.

따라서 현재의 소프트웨어 개발에서는 일반적으로 이들 중 어느 것과도 직접 대화할 수 없습니다.그래픽스 프로그램을 작성한 것처럼 HDMI와일반적으로 DisplayPort.

문제는 시스템이 무엇을 해야 하는지 아키텍처적으로 이해하고 그 작업을 수행하는 메커니즘을 사용하도록 시스템을 구성하느냐입니다(예를 들어 오늘날의 마이크로 서비스를 일반 시스템에 적용하는 모든 과제는 SOAP, CORBA 및 이전 프로토콜에 의해 이전에 해결된 오래된 문제입니다).

(JAX WS와 함께) SOAP 웹 서비스를 작성하는데 몇 년을 소비하고 있습니다.그것들은 쓰기 어렵지 않다.단일 엔드포인트와 단일 HTTP 메서드(POST)라는 아이디어도 마음에 듭니다.저는 REST가 너무 장황해요.

그러나 데이터 컨테이너로서 JSON은 더 단순하고, 더 작고, 더 읽기 쉽고, 더 유연하며, 프로그래밍 언어에 가까워 보입니다.

그래서 저는 AJAX 요청에 대한 백엔드를 작성하는 방법을 고안해 냈습니다.비교:

기타:

• 사용자 가져오기: 메서드 GET https://example.com/users/ {id}
• update user: 메서드 POST https://example.com/users/ (요청 본문에 User 객체가 있는 JSON)

RPC:

• get user: 메서드 GET https://example.com/getUser?id=1
• update user: 메서드 POST https://example.com/updateUser (요청 본문에 User 객체가 있는 JSON)

마이웨이(제안명은 JOH - JSON over HTTP):

• get user: 메서드 POST https://example.com/ (JSON은 요청을 처리하는 사용자 ID와 클래스/패킷을 모두 지정합니다)
• update user: 메서드 POST https://example.com/ (JSON은 요청을 처리하는 사용자 개체와 클래스/패킷을 모두 지정합니다)

언급URL : https://stackoverflow.com/questions/8323950/why-use-xmlsoap-when-json-so-simple-and-easy-to-handle