Tôi có nên phân tích cú pháp XML trên máy chủ hoặc cung cấp proxy và để trình duyệt phân tích cú pháp không?

Tôi cần giao diện với API của bên thứ 3. Với API này, tôi tạo một yêu cầu GET từ bên trong trình duyệt của người dùng cuối và nhận được phản hồi XML. Dữ liệu này được sử dụng trong một ứng dụng dựa trên trình duyệt nơi người dùng có thể tìm kiếm thông qua nó, sử dụng nó để đưa ra quyết định, v.v. Vấn đề chính là hầu hết các trình duyệt đã khóa sử dụng XML tên miền chéo, vì vậy tôi không thể đơn giản nhận được XML từ API.

Tuy nhiên, dữ liệu tổng thể về cơ bản được chia thành hai bộ.

1. Tập dữ liệu đầu tiên là công khai và chỉ cần được cập nhật thường xuyên, do đó, nó có thể được lưu trong bộ nhớ cache cho tất cả người dùng ở phía máy chủ, làm giảm lưu lượng đáng kể.
2. Nhóm dữ liệu thứ hai là riêng tư và cá nhân cho mỗi người dùng. Dữ liệu này cũng được cập nhật trong API thường xuyên hơn. Điều này dẫn đến bộ nhớ đệm sẽ kém hiệu quả hơn nhiều.

Vì lý do khả năng mở rộng, tôi muốn giữ cho máy chủ tải nhỏ nhất có thể.

Tôi thấy hai lựa chọn trước tôi:

1. Cung cấp một proxy có thể được sử dụng để định tuyến các yêu cầu XML đến máy chủ của bên thứ 3 và trực tiếp qua lại giữa API của khách hàng và bên thứ ba.
2. Yêu cầu máy chủ thực hiện chuyển đổi từ XML sang JSON và loại bỏ thông tin không cần thiết. Điều này về cơ bản có nghĩa là tạo một API mới cho máy chủ của chúng tôi, nó chuyển thành các yêu cầu từ API của bên thứ 3

Điều gì sẽ là cách tốt nhất để cung cấp dữ liệu cho người dùng? (Không phải là một trong hai tùy chọn)

Tùy chọn proxy là cách dễ nhất để thực hiện. Bạn không có bất kỳ sự phát triển tùy chỉnh nào để làm, điều duy nhất cần làm là thiết lập proxy. Điều này cũng đơn giản: không có mã bổ sung để duy trì và nếu API thay đổi, bạn không có thay đổi nào để thực hiện về phía mình.

Một proxy sẽ là một lựa chọn ưu tiên:

• Nếu bạn cần vận chuyển phần mềm làm việc nhanh chóng. Điều này làm cho nó trở thành một lựa chọn tốt, ví dụ, nếu bạn định gửi một tính năng, nhưng được tìm thấy trong giai đoạn thực hiện dự án mà bạn không thể thực hiện các yêu cầu AJAX tên miền chéo.

• Hoặc nếu API hiện tại được thiết kế tốt : kiến ​​trúc tốt, các cuộc gọi rất rõ ràng, tài liệu đầy đủ và dễ hiểu.

• Hoặc nếu API hiện tại có thể thay đổi. Nếu nó thay đổi, bạn chỉ cần thay đổi triển khai JavaScript. Nếu thay vì proxy, bạn đang phân tích kết quả và tạo JSON của riêng mình, có nguy cơ các thay đổi đối với API sẽ yêu cầu các thay đổi trong mã phía máy chủ của bạn.

Mặt khác, phân tích kết quả có một lợi ích để có thể trừu tượng hóa hoàn toàn API ở phía máy khách. Đây là một giải pháp thay thế chậm hơn, vì nó yêu cầu thiết kế giao diện mới (nếu API ban đầu không được thiết kế tốt) và để thực hiện các tính năng trích xuất, chuyển đổi và tải, nhưng nó có thể là lựa chọn dài hạn tốt cho một dự án lớn. Đây là một lựa chọn ưu tiên:

• Nếu bạn cần các tính năng bổ sung. Bạn có thể khai thác các tính năng khác nhau không có trong API gốc, chẳng hạn như lưu vào bộ đệm ở mức không được máy chủ proxy thông thường hoặc mã hóa hoặc mô hình xác thực khác hỗ trợ .

  Ví dụ: nếu số lượng yêu cầu AJAX trở thành vấn đề hoặc nếu mô hình giao tiếp hai chiều có ý nghĩa, bạn có thể triển khai Web Sockets.

• Hoặc nếu API hiện tại không được thiết kế tốt. Giống như một mẫu mặt tiền, phương pháp này cho phép bạn thiết kế lại API. Nếu bản gốc kém, việc có mặt tiền giúp giải quyết các lựa chọn thiết kế xấu được thực hiện bởi các tác giả ban đầu của API kế thừa. Bạn có thể hành động tốt trên các phần lớn, chẳng hạn như kiến ​​trúc tổng thể của API, mà còn về các chi tiết, chẳng hạn như tên của các đối số hoặc thông báo lỗi.

  Mặc dù việc sửa đổi API tồn tại đôi khi là không thể, nhưng có một mặt tiền có thể làm việc với một đoạn mã sạch sẽ trừu tượng hóa các nhược điểm và lỗi trong thiết kế ban đầu.

• Hoặc nếu API hiện tại có thể thay đổi. Thật vậy, bạn có thể thích thay đổi mã phía máy chủ thay vì JavaScript nếu API thay đổi theo thời gian, trong khi vẫn giữ cho giao diện chung của mặt tiền của bạn không bị ảnh hưởng. Có thể dễ dàng hơn vì bạn có nhiều kinh nghiệm hơn với lập trình phía máy chủ hoặc vì bạn biết nhiều công cụ hơn để tái cấu trúc phía máy chủ hoặc vì dự án của bạn dễ dàng hơn trong việc xử lý phiên bản mã phía máy chủ.

Bạn có thể nhận thấy rằng tôi đã bỏ qua việc nói về JSON, hiệu năng, bộ đệm, v.v. Có một lý do cho điều đó:

• JSON so với XML: tùy thuộc vào bạn để chọn công nghệ phù hợp . Bạn làm điều đó bằng cách đo lường một cách khách quan sự quá nhiệt của XML so với JSON, thời gian cần thiết để tuần tự hóa dữ liệu và dễ dàng phân tích cú pháp.

• Hiệu suất: điểm chuẩn các triển khai khác nhau, chọn cách nhanh nhất, sau đó lập hồ sơ và tối ưu hóa dựa trên kết quả từ trình lược tả. Dừng khi bạn đạt được hiệu suất được chỉ định trong các yêu cầu phi chức năng.

  Ngoài ra, hiểu những gì bạn đang cố gắng để đạt được. Có một số phần tương tác với nhau: API gốc, băng thông giữa máy chủ của bạn và API, hiệu suất của máy chủ, băng thông giữa máy chủ của bạn với người dùng cuối và hiệu suất của máy. Nếu bạn được yêu cầu nhận được phản hồi cho yêu cầu trong vòng 30 ms, nhưng API ban đầu dành 40 ms. xử lý yêu cầu, bất kể bạn làm gì, bạn sẽ không thể có được hiệu suất được yêu cầu.

• Bộ nhớ đệm: bộ nhớ đệm là một trong những kỹ thuật giúp ứng dụng web của bạn cảm thấy nhanh hơn, giảm băng thông, v.v.

  1. Hãy chắc chắn rằng bạn cũng sử dụng bộ nhớ đệm của máy khách (bộ nhớ đệm phía máy chủ sẽ không làm giảm việc sử dụng băng thông giữa bạn và khách hàng), vì việc thiết lập các tiêu đề HTTP đúng cách thường rất khó khăn.

  2. Hãy chắc chắn rằng bạn xác định chính xác những gì cần lưu trữ trong bộ nhớ cache, trong bao lâu và khi nào để vô hiệu hóa nó: nếu mô tả của sản phẩm đã thay đổi 10 giây trước, nhưng khách hàng của một trang web thương mại điện tử vẫn thấy phiên bản cũ, thì vẫn ổn. Nếu chủ sở hữu thay đổi mô tả, gửi nó và vẫn thấy biến thể trước đó do bộ đệm, đây là vấn đề.

  3. Đừng chỉ tập trung vào bộ nhớ đệm. Giảm thiểu, ví dụ, cũng quan trọng. Giảm số lượng yêu cầu cũng có thể có lợi.

Có một tùy chọn thứ ba mà bạn có thể chưa thấy: Chia sẻ tài nguyên nguồn gốc chéo (CORS) .

Tiêu chuẩn CORS hoạt động bằng cách thêm các tiêu đề HTTP mới cho phép máy chủ phân phát tài nguyên cho các miền gốc được phép. Các trình duyệt hỗ trợ các tiêu đề này và tôn trọng các hạn chế mà chúng thiết lập.

Ví dụ : Giả sử trang web của bạn là http://my-cool-site.com và, bạn có API của bên thứ ba tại tên miền http://third-party-site.com , nơi bạn có thể truy cập qua AJAX.

Và giả sử rằng một trang mà bạn phục vụ từ my-cool-site.com đã gửi yêu cầu đến third-party-site.com. Thông thường, trình duyệt của người dùng sẽ từ chối các cuộc gọi AJAX đến bất kỳ trang web nào khác ngoài tên miền / tên miền phụ của bạn theo Chính sách bảo mật cùng nguồn gốc . Nhưng nếu trình duyệt và máy chủ của bên thứ ba hỗ trợ CORS, những điều sau đây sẽ xảy ra:

• Trình duyệt sẽ gửi tiêu đề HTTP sau tới third-party-site.com

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

• Nếu máy chủ của bên thứ ba chấp nhận yêu cầu từ tên miền của bạn, nó sẽ phản hồi với tiêu đề HTTP sau:

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

• Để cho phép tất cả các tên miền, máy chủ của bên thứ ba có thể gửi tiêu đề này:

  Access-Control-Allow-Origin: *

• Nếu trang web của bạn không được phép, trình duyệt sẽ đưa ra lỗi.

Nếu máy khách có các trình duyệt khá hiện đại hỗ trợ CORS và máy chủ bên thứ ba của bạn cũng hỗ trợ CORS , bạn chắc chắn có thể sử dụng nó với các thay đổi nhỏ đối với mã của mình.

Tôi đã tìm thấy một lời giải thích hay về CORS , trên đó bạn cũng sẽ tìm thấy một cách khác để làm điều này: JSONP . Nhưng JSONP sẽ yêu cầu một số lượng thay đổi hợp lý cho mã của bạn.

Để thực hiện một yêu cầu CORS, bạn chỉ cần sử dụng XMLHttpRequesttrong Firefox 3.5+, Safari 4+ và Chrome và XDomainRequestđối tượng trong IE8 +. Khi sử dụng XMLHttpRequestđối tượng, nếu trình duyệt thấy rằng bạn đang cố gắng thực hiện một yêu cầu tên miền chéo, nó sẽ kích hoạt liên tục hành vi CORS.

Đây là một chức năng javascript giúp bạn tạo một đối tượng CORS trình duyệt chéo.

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;
}

Vì bạn nói rằng "hầu hết các trình duyệt đã khóa sử dụng XML tên miền chéo", tôi đoán máy chủ bên thứ ba của bạn có thể không hỗ trợ CORS. Sau đó, bạn phải tìm cách tiếp cận thay thế.

Vì lý do khả năng mở rộng, tôi muốn giữ cho máy chủ tải nhỏ nhất có thể

Tôi nghĩ rằng điều này ít nhiều chỉ vào câu trả lời. Việc có cung cấp dữ liệu đã xử lý trước cho khách hàng hay không phụ thuộc chủ yếu vào:

1. sự khác biệt về giao thông
2. tác động hiệu suất của quá trình xử lý
3. tác động của một định dạng dữ liệu khác nhau trên máy khách

Nếu XML tương đối nhỏ hoặc chỉ có một vài yêu cầu, thì có thể chỉ cần chuyển tiếp nó đến máy khách và quên nó đi. Điều tương tự cũng đúng khi dữ liệu được xử lý trước vẫn là một phần lớn của dữ liệu gốc hoặc nếu khách hàng không thể kiếm được nhiều tiền từ một định dạng dữ liệu khác (ví dụ như JSON).

Tuy nhiên, nếu máy khách đấu tranh với việc xử lý một tập dữ liệu XML lớn hoặc nếu máy khách chỉ cần một phần nhỏ dữ liệu XML gốc, thì có thể có ý nghĩa để thực hiện một số tiền xử lý ở phía máy chủ.

Cuối cùng, việc mở rộng quy mô máy chủ sẽ dễ dàng hơn so với quy mô máy khách / trình duyệt hoặc băng thông có sẵn. Để đặt nó trong một câu, nó phụ thuộc vào vị trí nút cổ chai trong hệ thống.

Lựa chọn của tôi sẽ là lưu trữ và nén (loại bỏ thông tin không cần thiết) và kết quả gzip cho trình duyệt máy khách, tùy chọn # 2 của bạn . Bởi vì các trình duyệt thường không phải là CPU cao cấp và các dòng máy chủ đến trình duyệt có dung lượng hạn chế. Tôi đang nói về khách hàng di động . Nếu bạn không có kế hoạch hỗ trợ khách hàng di động thì hãy chọn bất cứ điều gì đơn giản hơn, ví dụ như một sốGoogle:CORS proxy