Json과 XML을 모두 REST 인터페이스에 출력으로 제공하려는 이유는 무엇입니까?

Json과 XML을 모두 REST 인터페이스에 출력으로 제공하려는 이유는 무엇입니까?

"REST 프레임워크" 벤더가 Json 기반 표현과 XML 기반 표현을 모두 반환하는 지원을 제공하려는 이유는 이해하지만, 왜 사람들은 동일한 서비스에서 두 가지 표현을 모두 반환하려고 합니까?

• 사용 가능한 Json 파서가 없는 플랫폼을 기반으로 구축된 클라이언트 애플리케이션이 있기 때문입니까?

• 더 많은 사람에게 어필할 수 있기 때문에, 인터페이스의 보급을 확대하는 것을 바라고 있기 때문입니까?

• 모든 RESTful 인터페이스가 표준 규약을 따르고 있다고 느끼기 때문입니까?

둘 다 제공하는 경우:

Json 형식과 호환되도록 XML의 네임스페이스를 사용하지 않으시겠습니까?또는 모든 데이터 요소에 대해 하나의 네임스페이스만 있습니까?

속성과 요소를 일관된 Json 형식으로 매핑하기 위한 표준화된 메커니즘이 있습니까? 아니면 XML에서 속성을 사용하지 않도록 해야 합니까?

표현마다 다른 엔드포인트를 작성합니까, 아니면 콘텐츠네고시에이션을 사용하여 요청된 형식을 전달합니까?기본 포맷이 있습니까?

편집 가능한 리소스에 캐시를 사용하고 다른 URL을 사용하는 경우, 한 표현이 비활성화되었을 때 다른 표현도 비활성화되도록 하려면 어떻게 해야 합니까?

여러 형식을 지원하는 것이 필요한 노력을 기울일 가치가 있다고 생각하십니까?

응답 요약:

그래서 가장 중요한 이유는 선호도 중 하나인 것 같습니다.일부 개발자는 물결 괄호를 선호하고 일부는 꺾쇠 괄호를 선호합니다.

XML에서 Json으로 마이그레이션하려는 사용자도 있으므로 이전 버전과의 호환성을 위해 둘 다 지원이 필요합니다.

Json을 사용하고 싶은 사람도 있지만, Json을 무서워하는 개발자가 있는 것을 염려하고 있기 때문에, 누구에게도 불쾌감을 주지 않기 위해서 양쪽 모두를 서포트하고 있습니다.

프레임워크 XYZ에서는 이 기능을 사용하기 쉬우니 왜 안됩니까?

또 하나의 흥미로운 제안 이유는 JSON을 사용하여 짧은 데이터 요약을 제공하고 XML을 의미론적으로 풍부한 완전한 표현으로 사용할 수 있다는 것입니다.

지금까지의 이야기와는 전혀 다른 이유--

REST 인터페이스는 리소스에 관한 인터페이스이며, 각 리소스에는 URL이라는 식별자가 있습니다. XML, JSON, HTML 등 리소스를 다른 직렬화 방식으로 사용하려는 이유만으로 동일한 리소스에 대해 설명합니다.

따라서 XML과 JSON에 다른 경로를 제공하는 대신 'Accept' 헤더를 사용하여 클라이언트가 원하는 대상을 결정합니다.경우에 따라 서비스는 'Accept-Language' 헤더를 사용하여 메타데이터에 사용할 언어를 결정합니다.

시맨틱 웹의 경우 레코드의 다른 시리얼라이제이션에 다른 식별자를 할당하면 '같은' 개체를 설명하는 모든 레코드에 링크하기 위해 추가 정보를 포함해야 합니다.

이러한 작업에 대한 자세한 내용은 Linked Data(링크 데이터)라는 용어로 확인할 수 있습니다.단, 일반적으로는 시리얼라이제이션에서 RDF를 사용하는 것을 의미합니다.

업데이트: 특정 형식과의 링크에 대한 논의와 함께, 추상적인 '작품'으로서의 '책'과 물리적 '항목' 사이의 관계에 대한 개념적 모델을 가진 '서적 기록의 기능적 요건'(FRBR)을 읽어보는 것도 추천합니다.FRBR의 라이브러리, 정보 및 시멘틱 웹 커뮤니티에서는 디지털 객체와 어떻게 관련되어 있는지에 대한 약간의 논의가 있었습니다.

기본적으로 여러 수준에서 식별자를 할당할 수 있으며(리소스 및 리소스에 대한 메타데이터 텍스트 또는 리소스에 대한 메타데이터 텍스트의 직렬화 등), 각각 고유한 용도를 사용할 수 있습니다.

대체 형식 또는 언어를 포함하여 개체 간의 관계를 보고하기 위한 규격에 대한 OAI-ORE가 표시될 수도 있습니다.

Json은 클라이언트 측 스크립트에 적합한 경우가 많습니다.이것은 초경량 응답이며 JavaScript 프레임워크의 대부분은 파서가 내장되어 있습니다.한편, 많은 서버측 애플리케이션과 언어는 여전히 XML에 크게 의존하고 있습니다.예를 들어 Java입니다.

물론 XML은 JavaScript와 Java(및 다른 프로그래밍 언어의 대부분)로 구문 분석할 수 있으며 적어도 하나의 Json 파서가 있습니다.그러나 현재로서는 이것이 가장 일반적인 관행으로 보인다.

"실장 vs 이점" 토픽에 대해 말하자면, 저는 대부분 Ruby와 함께 일합니다. Ruby on Rails는 같은 소스에서 몇 초 안에 Json 또는 XML 응답을 생성할 수 있습니다.이 경우 문제가 되지 않으며 도움이 될 것 같으면 보통 이 기능을 추가합니다.

PHP와 같은 다른 테크놀로지에서는 더 많은 노력이 필요하고 구현 비용도 다릅니다.이것이 기본적인 기능이 아닌 이상, 다른 버전에 제공할 필요가 없을 때까지 한 가지 답변을 고수할 것입니다.

나는 REST, SOAP, POX 및 JSON Web Services의 역사에 대해 꽤 장황한 기사를 썼다.기본적으로 다양한 옵션의 존재와 이점에 대해 자세히 설명합니다. 안타깝게도 여기에 모든 콘텐츠를 나열하기에는 너무 깁니다.

기본적으로 XML은 보다 상세하고 엄격하며 검증 가능하기 때문에 상호 운용성이 우수하지만 대부분의 프로그래밍 언어에는 적합하지 않습니다.또한 XSD/DTD 문서에서 찾을 수 있는 스키마(데이터에 대한 메타데이터) 개념도 지원합니다.WSDL은 XSD의 확장으로 웹 서비스(SOAP Web Services 등)의 무한 상세 기술도 지원합니다.

JSON은 JSON 문자열이 네이티브하게 평가()될 수 있기 때문에 JavaScript에 가장 적합한 "Serialized JSON"인 보다 가볍고 느슨한 형식의 텍스트 형식입니다.네임스페이스와 개념 속성/요소가 부족하기 때문에 대부분의 다른 프로그래밍 언어에도 적합합니다.유감스럽게도 기본 유형만 지원됩니다.숫자, 문자열, 부울, 객체 및 배열.따라서 상호 운용성을 위한 최선의 선택은 아닙니다.

이 둘을 비교하는 Northwind 데이터베이스 벤치마크를 몇 가지 가지고 있는데, XML은 동등한 데이터셋의 평균 JSON의 2배 크기인 것 같습니다.XML 문서에 여러 네임스페이스가 포함되어 있으면 페이로드가 그 이상으로 확장될 수 있습니다.

REST 인터페이스만 생성하기 때문에 이에 대한 직접적인 정보는 없습니다."내부" 소비용으로 사용됩니다.

퍼블릭 API의 프로바이더는, 계속 진화하고, 페이스가 빠르고, 경쟁이 치열한 환경에서, 단지 「베팅의 회피」에 지나지 않는다고 생각합니다.

게다가 비교적 단순한 오브젝트 모델(대부분의 오브젝트 모델)의 경우, 양쪽 포맷을 처리하기 위한 추가 노력은 최소이며, 따라서 가치가 있을 것입니다.

나는 "사람들이 왜 그러는지"가 꽤 상황적이라고 생각한다.잠재적인 광범위한 고객을 위한 애플리케이션을 개발하는 경우, 여러 콘텐츠 유형을 지원하면 시장성이 향상될 수 있습니다. 즉, 다양한 콘텐츠 유형의 의미를 이해하고 있는 사람과 그렇지 않은 사람 모두에게 시장성이 향상될 수 있지만, 최신의 가장 중요한 유행어를 지원하는 것을 좋아합니다.

두 가지를 모두 지원하는 몇 가지 이유가 기술적으로 더 정당할 수 있습니다.어플리케이션에서는 페이지 정보를 취득하기 위한 Ajaxy 브라우저 클라이언트의 기능(JSON이 좋은 경우)이 필요할 수 있습니다.또한 백그라운드 또는 배치 처리를 수행할 수 있는 일부 스탠드아론 API 클라이언트를 지원해야 합니다.이 경우 XML 라이브러리가 더 편리합니다.

다른 엔드포인트를 사용하면 REST 리소스에 동일한 리소스에 대해 여러 URI가 제공되므로 콘텐츠네고시에이션을 사용하는 것이 다른 엔드포인트보다 선호됩니다.이 때문에 API가 애매하고 혼란스러울 수 있습니다.

결국, "노력할 가치가 있다"는 가치는 여러 컨텐츠 유형을 지원하는 데 대한 투자 수익을 얻을 수 있는지 여부에 달려 있다고 생각합니다.어느 누구도 두 가지 콘텐츠 유형 중 하나를 사용하지 않을 경우, 왜 두 가지 콘텐츠 유형을 모두 지원합니까?물론 쿨할 수도 있지만 대부분의 경우 YAGNI에도 해당될 수 있습니다.

나는 그것에 대해 너무 많이 읽지는 않을 것이다.일부 개발자는 다른 개발자보다 하나를 선호하며, (특히 프레임워크에 따라) 둘 다 제공하기가 매우 쉽다고 생각합니다.

지금까지 본 API의 대부분은 XML 네임스페이스에 구애받지 않습니다.

정말 많은 개발자들이 JSON을 이해하지 못한다.가벼운 등이라고 하는 것은 알지만, 많은 프로그래머는 사이클을 사용하여 문제를 해결하고 싶어하지 않습니다.고객은 XML을 잘 알고 있으며, XML에 익숙하며, 결국 XML을 사용하고 싶어합니다.또한 JSON은 JavaScript와 관련되어 있다는 오명을 가지고 있으며, 이는 자동적으로 많은 사람들에게 해를 끼치게 됩니다.

API를 작성하는 대상 사용자에 따라 두 가지 모두를 지원할 수 있습니다. 오래된 기술을 사용하는 비즈니스 프로그래머가 많다면 둘 다 지원할 가치가 있습니다.최첨단 테크놀로지 업계를 위해 구축한다면 xml을 지원할 가치가 없을 수 있습니다.제가 일하는 곳에서는 두 가지를 모두 지원해야 하는데, 그렇게 하는 것이 가치 있는 일입니다.우리는 고객이 무엇을 원하는지 알고 있으며, 그들은 우리에게 돈을 주고 그것을 제공해 줍니다.

대부분의 경우 이 서비스는 몇 년 전만 해도 유일한 솔루션이었던 XMP/SOAP에서 시작되었습니다.그러나 최근(최근 2년 정도) JSON의 인기가 높아짐에 따라 대부분의 서비스에서는 JSON도 지원하기로 결정하였고, 이미 XML 인터페이스가 있었기 때문에 JSON을 그대로 유지했습니다.

개인적으로 JSON은 대역폭에 대한 각도 과세를 피하기 위해 서버만 선호합니다.또한 JSON이 매우 린 스펙이라는 점도 매력적입니다.

경험상 Java 및 C# 개발자는 XML을 오브젝트에 반영할 수 있는 기능을 선호합니다.JSON은 동적인 동작(신비주의 또는 리스피즘)을 일으키기 쉽기 때문에 문제가 발생하지 않는 스태틱 타이핑의 행복감을 얻을 수 있습니다.

PHP와 Ruby 프로그래머들은 신경 쓰지 않는 경향이 있다.

AJAX 개발자는 eval()이 파서이기 때문에 JSON을 선호합니다(내장되어 고속).

서비스를 어떻게 소비하느냐에 따라 달라집니다.저는 현재 JSON과 XML을 모두 공개하는 서비스를 하고 있습니다.

1. 클라이언트 중 일부는 모바일 앱이기 때문에 JSON이 적합하기 때문에 XML에 비해 JSON 해석에 필요한 처리 능력이 적습니다.
2. 제 고객 중 일부는 JavaScript를 사용하는 웹 페이지가 될 것입니다.JSON은 Java Script의 1등급 사용자이며 브라우저가 실행되는 시스템의 컴퓨팅 성능을 확신할 수 없기 때문에 JSON은 매우 적합합니다.
3. 다른 클라이언트는 서버 측 컴포넌트이며 XML을 쉽게 처리할 수 있습니다.또한 그 팀의 개발자는 XML에 정통하기 때문에 XML을 선호합니다.

따라서 JSON과 XML이 혼재하는 서비스에서는 JSON과 XML이 모두 매우 적합합니다.

accept 헤더를 사용하여 반환할 응답 종류를 결정합니다.Jackson과 Jersey를 함께 사용하면 정말 쉬워집니다.각각을 개별적으로 처리하기 위해 특별한 코딩이 필요하지 않습니다.네임스페이스도 Atribute도 사용하지 않습니다.

언급URL : https://stackoverflow.com/questions/1649793/why-do-people-want-to-deliver-both-json-and-xml-as-output-to-their-rest-interfac