서버에서 XML을 구문 분석하거나 프록시를 제공하여 브라우저에서 구문 분석해야합니까?

타사 API와 인터페이스해야합니다. 이 API를 사용하여 최종 사용자의 브라우저에서 GET 요청을하고 XML 응답을받습니다. 이 데이터는 사용자가 검색하고 결정을 내리는 데 사용할 수있는 브라우저 기반 응용 프로그램에서 사용됩니다. 주요 문제는 대부분의 브라우저가 도메인 간 XML 사용을 차단했기 때문에 간단히 얻을 수 없다는 것입니다. API의 XML

그러나 전체 데이터는 기본적으로 두 세트로 나뉩니다.

1. 첫 번째 데이터 세트는 공개적이며 자주 업데이트해야하므로 서버 측의 모든 사용자를 위해 캐시 할 수 있으므로 트래픽이 상당히 줄어 듭니다.
2. 두 번째 데이터 세트는 개인 및 개인마다 다릅니다. 이 데이터는 API에서 더 자주 업데이트됩니다. 이로 인해 캐싱이 훨씬 덜 효과적입니다.

확장 성 때문에 서버로드를 가능한 작게 유지하고 싶습니다.

내 앞에 두 가지 옵션이 있습니다.

1. XML 요청을 써드 파티 서버로 라우팅하고 클라이언트와 써드 파티 API간에 직접 앞뒤로 라우팅하는 데 사용할 수있는 프록시를 제공하십시오.
2. 서버가 XML에서 JSON으로 변환하고 불필요한 정보를 제거하도록하십시오. 이것은 본질적으로 우리 서버를 위해 새로운 API를 만드는 것을 의미하며, 이는 타사 API의 요청으로 변환됩니다.

사용자에게 데이터를 제공하는 가장 좋은 방법은 무엇입니까? (두 옵션 중 하나 일 필요는 없습니다)

프록시 옵션은 구현하기 가장 쉬운 방법입니다. 할 사용자 정의 개발이 없으며 프록시를 설정하기 만하면됩니다. 또한 간단합니다. 유지해야 할 추가 코드가 없으며 API가 변경되면 변경해야 할 사항이 없습니다.

프록시가 선호되는 선택입니다.

• 작동하는 소프트웨어를 빨리 배송해야하는 경우. 예를 들어, 기능을 제공하려고했지만 프로젝트의 구현 단계에서 도메인 간 AJAX 요청 만 할 수없는 경우에 적합합니다.

• 또는 현재 API가 잘 설계된 경우 : 아키텍처가 양호하고 호출이 매우 명확하며 문서가 완전하고 이해하기 쉽습니다.

• 또는 현재 API가 변경 될 수 있습니다. 변경되면 JavaScript 구현 만 변경하면됩니다. 프록시 대신 결과를 구문 분석하고 자체 JSON을 생성하는 경우 API를 변경하면 서버 측 코드를 변경해야 할 위험이 있습니다.

반면에 결과를 구문 분석하면 클라이언트 측에서 API를 완전히 추상화 할 수 있다는 이점이 있습니다. 새로운 인터페이스를 설계하고 (원래 API가 제대로 설계되지 않은 경우) 추출, 변환 및로드 기능을 구현해야하기 때문에이 방법은 속도가 느리지 만 대규모 프로젝트에는 장기적으로 좋은 선택 일 수 있습니다. 이것은 선호되는 선택입니다.

• 추가 기능이 필요한 경우 일반 프록시 서버에서 지원하지 않는 레벨의 캐싱 , 암호화 또는 다른 인증 모델 과 같이 원래 API에서 사용할 수 없었던 다양한 기능을 활용할 수 있습니다 .

  예를 들어, AJAX 요청 수가 문제가되거나 양방향 통신 모델이 적합한 경우 웹 소켓을 구현할 수 있습니다.

• 또는 현재 API가 제대로 설계되지 않은 경우 파사드 패턴과 마찬가지로이 접근 방식을 사용하면 API를 다시 디자인 할 수 있습니다. 원래 디자인이 좋지 않은 경우 파사드를 사용하면 레거시 API의 원래 작성자가 잘못된 디자인 선택을 해결할 수 있습니다. API의 전체 아키텍처와 같은 큰 부분뿐만 아니라 인수 이름 또는 오류 메시지와 같은 세부 사항에서도 잘 작동 할 수 있습니다.

  기존 API를 수정하는 것은 때때로 불가능하지만 파사드를 사용하면 원래 디자인의 단점과 오류를 추상화하는 깨끗한 코드로 작업 할 수 있습니다.

• 또는 현재 API가 변경 될 수 있습니다. 실제로 API의 시간이 지남에 따라 API가 변경되면 파사드의 공용 인터페이스에는 영향을 미치지 않으면 서 JavaScript 대신 서버 측 코드를 변경하는 것이 좋습니다. 서버 측 프로그래밍에 대한 경험이 많거나 서버 측 리팩토링을위한 더 많은 도구를 알고 있거나 프로젝트에서 서버 측 코드 버전 관리를보다 쉽게하기 때문에 더 쉬울 수 있습니다.

JSON, 성능, 캐싱 등에 대해 언급하지 않은 것을 알 수 있습니다. 그 이유는 다음과 같습니다.

• JSON과 XML : 올바른 기술 을 선택하는 것은 전적으로 사용자의 몫 입니다. JSON을 통한 XML의 과열, 데이터를 직렬화하는 데 걸리는 시간 및 구문 분석의 용이성을 객관적으로 측정하여 수행합니다.

• 성능 : 다양한 구현을 벤치마킹하고 가장 빠른 구현을 선택한 다음 프로파일 러의 결과에 따라 프로파일 링하고 최적화하십시오. 비 기능 요구 사항에 지정된 성능을 달성하면 중지하십시오.

  또한 달성하려는 목표를 이해하십시오. 원래 API, 서버와 API 사이의 대역폭, 서버 성능, 서버와 최종 사용자 사이의 대역폭 및 머신 성능과 같이 서로 상호 작용하는 여러 부분이 있습니다. 30ms 이내에 요청에 대한 응답을 요청했지만 원래 API는 40ms를 소비합니다. 무엇을 하든지 요청을 처리하면 필요한 성능을 얻을 수 없습니다.

• 캐싱 : 캐싱은 웹 응용 프로그램의 속도를 높이고 대역폭을 줄이는 등의 기술 중 하나입니다.

  1. HTTP 헤더를 올바르게 설정하는 것이 까다로울 수 있으므로 클라이언트 캐싱도 사용하십시오 (서버 측 캐싱은 사용자와 고객 간의 대역폭 사용량을 줄이지 않습니다).

  2. 캐시 할 대상, 유효 기간 및시기를 정확하게 결정해야합니다. 제품 설명이 10 초 전에 변경되었지만 전자 상거래 웹 사이트의 고객이 여전히 이전 버전을 볼 수 있으면 문제가 없습니다. 소유자가 설명을 변경하고 제출 한 후에도 캐싱으로 인해 이전 변형이 계속 표시되면 문제가됩니다.

  3. 캐싱에만 집중하지 마십시오. 예를 들어 축소도 중요합니다. 요청 수를 줄이는 것도 도움이 될 수 있습니다.

이 세 번째 : 당신이 본 않았을 수 있습니다 옵션 간 리소스 공유 (CORS가) .

CORS 표준은 서버가 허용 된 오리진 도메인에 자원을 제공 할 수있는 새로운 HTTP 헤더를 추가하여 작동합니다. 브라우저는 이러한 헤더를 지원하고 설정 한 제한을 준수합니다.

예 : 사이트가 http://my-cool-site.com 이고 도메인 http://third-party-site.com에 타사 API가 있으며 AJAX를 통해 액세스 할 수 있다고 가정하십시오 .

그리고 my-cool-site.com의 서버 페이지가 third-party-site.com에 요청했다고 가정합니다. 일반적으로 사용자 브라우저는 동일 출처 보안 정책에 따라 자신의 도메인 / 하위 도메인 이외의 다른 사이트에 대한 AJAX 호출을 거부합니다 . 그러나 브라우저와 타사 서버가 CORS를 지원하면 다음과 같은 일이 발생합니다.

• 브라우저는 다음 HTTP 헤더를 third-party-site.com으로 보냅니다.

  Origin: http://my-cool-site.com

• 타사 서버가 도메인의 요청을 수락하면 다음 HTTP 헤더로 응답합니다.

  Access-Control-Allow-Origin: http://my-cool-site.com

• 모든 도메인을 허용하기 위해 타사 서버는 다음 헤더를 보낼 수 있습니다.

  Access-Control-Allow-Origin: *

• 사이트가 허용되지 않으면 브라우저에 오류가 발생합니다.

클라이언트에 CORS를 지원하는 상당히 최신 브라우저가 있고 타사 서버도 CORS 를 지원 하는 경우 코드를 약간만 변경하여 사용할 수 있습니다.

내가 발견 CORS에 좋은 설명 : 당신은이 작업을 수행하는 다른 방법을 찾을 수있는, JSONP를 . 그러나 JSONP는 코드를 상당히 변경해야합니다.

CORS 요청을하려면 XMLHttpRequestFirefox 3.5 이상, Safari 4 이상 및 Chrome XDomainRequest에서 사용하고 IE8 이상에서 개체를 사용하면됩니다. XMLHttpRequest객체를 사용할 때 브라우저가 도메인 간 요청을 시도하는 것을 발견하면 CORS 동작을 원활하게 트리거합니다.

다음은 크로스 브라우저 CORS 오브젝트를 작성하는 데 도움이되는 Javascript 함수입니다.

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        // XHR has 'withCredentials' property only if it supports CORS
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){ // if IE use XDR
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}

"대부분의 브라우저가 도메인 간 XML 사용을 잠갔습니다"라고 말했기 때문에 타사 서버가 CORS를 지원하지 않을 수 있습니다. 그런 다음 다른 방법을 찾아야합니다.

확장 성 때문에 서버의 부하를 가능한 작게 유지하고 싶습니다

나는 이것이 대답을 어느 정도 가리키는 것이라고 생각합니다. 사전 처리 된 데이터를 클라이언트에 제공할지 여부는 주로 다음에 따라 다릅니다.

1. 교통량과의 차이
2. 처리의 성능 영향
3. 다른 데이터 형식이 클라이언트에 미치는 영향

XML이 비교적 작거나 요청이 적은 경우에는 클라이언트에게 전달하고 잊어 버리는 것이 좋습니다. 전처리 된 데이터가 여전히 원래 데이터의 많은 부분이거나 클라이언트가 다른 데이터 형식 (예 : JSON)에서 많은 이익을 얻을 수없는 경우에도 마찬가지입니다.

그러나 클라이언트가 큰 XML 데이터 세트를 처리하는 데 어려움을 겪거나 클라이언트가 원본 XML 데이터의 작은 부분 만 필요한 경우 서버 측에서 일부 전처리를 수행하는 것이 좋습니다.

결국 클라이언트 / 브라우저 또는 사용 가능한 대역폭을 확장하는 것보다 서버를 확장하는 것이 더 쉽습니다. 한 문장으로 표현하려면 시스템의 병목 현상 위치에 따라 다릅니다.

선택은 캐시 및 압축 (불필요한 정보를 버림) 및 gzip 결과를 클라이언트 브라우저 ( 옵션 # 2)에 저장하는 것 입니다. 브라우저는 일반적으로 고급 CPU가 아니며 서버 대 브라우저 네트워크 회선의 용량이 제한적입니다. 모바일 클라이언트 에 대해 이야기하고 있습니다 . 모바일 클라이언트를 지원할 계획이 없다면 더 간단한 것을 선택하십시오.Google:CORS proxy