Có phải là một ý tưởng tốt để hợp nhất nhiều yêu cầu HTTP để tiết kiệm băng thông?

Tôi đang chuẩn bị một ứng dụng một trang đôi khi sẽ được sử dụng qua kết nối di động chậm. Một số phần của nó khá nặng về các yêu cầu API (lấy mười tài nguyên khác nhau cho màn hình hiển thị mới).

Bây giờ, có phải là một ý tưởng tốt để hợp nhất các dịch vụ này với một dịch vụ cung cấp tất cả dữ liệu cần thiết, nhưng không phải là "thuần túy" theo các nguyên tắc REST? Có tăng hiệu suất đáng kể để được mong đợi?

Một trong những lợi thế của REST là khả năng lưu trữ các yêu cầu thông qua bộ đệm http truyền thống (giả sử rằng đây là những yêu cầu có thể lưu trong bộ nhớ cache).

Khi bạn có các yêu cầu đơn, lớn hơn, ít sử dụng hơn và có thể khác nhau (tôi sẽ tìm nạp các mục a,b,c,dlần này và các mục a,b,d,evào lần tới), bạn sẽ yêu cầu nhiều khả năng bị lỗi bộ nhớ cache và hết hạn từ bộ đệm có thể là ngồi đâu đó giữa bạn và nguồn.

Với hai bộ yêu cầu được đề cập ở trên, yêu cầu thứ hai có thể có tỷ lệ nhấn bộ nhớ cache 75% và được tìm nạp nhanh hơn đáng kể e, thay vì cả bốn điều.

Lưu ý rằng điều này có thể không rõ ràng ngay lập tức đối với những người sử dụng nó vì người thực hiện bộ yêu cầu bỏ lỡ bộ đệm đầu tiên sẽ vẫn có lỗi bộ nhớ cache.

Điều này không có nghĩa là nó sẽ lý tưởng trên kết nối mạng di động, nơi người ta ít có khả năng nhận được các lần truy cập bộ đệm không cục bộ. Nhưng đối với các điểm nóng hoặc các tình huống wifi khác, các lần truy cập bộ đệm có thể hữu ích hơn nhiều.

Phần lớn điều này, một lần nữa, tùy thuộc vào cách ứng dụng của bạn hoạt động. Có phải nó yêu cầu tất cả dữ liệu này khi khởi động? hoặc chúng ta đang nói về tải trang nơi kỳ vọng thời gian đáp ứng là khác nhau?

Điều lý tưởng cần làm là kiểm tra điều này để xem ứng dụng của bạn hoạt động như thế nào trong nhiều tình huống khác nhau. Cân nhắc thiết lập tình huống bạn đã gắn thiết bị di động của mình với mạng wifi cục bộ mà bạn có thể theo dõi (đó chỉ là lần truy cập đầu tiên trên google) và mô phỏng kết nối internet xấu để xem mọi thứ thực sự hoạt động như thế nào (hoặc không) và cái nào có hiệu suất tốt nhất.

Trực giác của bạn có phần đúng - bởi và thực hiện ít yêu cầu hơn chắc chắn là thích hợp hơn; API chunky có xu hướng tốt hơn. Đặc biệt với kết nối không chính xác, nơi bạn có thể thấy một số công việc và một số thất bại trong việc tạo ra các kịch bản dự phòng ác mộng vì không có gì có thể dựa vào bất cứ điều gì.

Có một cảnh báo lớn - bạn có thể trở nên quá táo bạo và các cuộc gọi và phản hồi của bạn trở nên cồng kềnh. Ví dụ, có thể có một cuộc gọi lớn khi bạn lần đầu tiên nhấn một trang và sau đó có các luồng cập nhật trong các vết cắn nhỏ hơn thay vì buộc làm mới một trang lớn mỗi khi bạn muốn dữ liệu.

Hoặc, bạn sẽ muốn làm cả hai cách trong tất cả các khả năng.

Kiểm tra bài viết Blog Dropbox Tech này .

Ở đó, họ mô tả chi tiết về lý do và cách họ triển khai chính xác giải pháp bạn đề xuất để truy xuất các hình thu nhỏ cho tất cả các hình ảnh của bạn. Cần phải nói rằng họ đo lường hiệu suất để xem liệu nó có đáng để gặp rắc rối không, và rõ ràng là có.

Tóm tắt ngắn gọn:

Trang web Dropbox phải tải hàng trăm hình thu nhỏ. Do những hạn chế trong một số trình duyệt, không phải tất cả các hình thu nhỏ được tải song song (các yêu cầu được xếp hàng). Họ muốn sử dụng SPDY , nhưng không thể làm như vậy vì các phần trong hệ thống của họ chưa hỗ trợ. Cuối cùng, họ đã sử dụng các yêu cầu hàng loạt qua HTTP, trả về nhiều hình thu nhỏ cho mỗi phản hồi ở dạng nén. Cải thiện tổng thời gian tải trang là 40% theo kết quả của họ.

Tóm lại: Cách tiếp cận của bạn có phần đúng và có thể được hưởng lợi từ Dịch vụ bao bọc.

Dịch vụ này sẽ kết hợp các cuộc gọi đơn hiện có vào một phương thức dịch vụ. Thực hiện điều đó bằng cách kết hợp các cuộc gọi từ khách hàng đến phía dịch vụ và sử dụng tất cả các cuộc gọi đơn lẻ, nguyên tử mà bạn có thể có ngay bây giờ.

Do đó, bạn sẽ tiếp tục được hưởng lợi từ REST như khả năng lưu trữ các yêu cầu.

Tuy nhiên, ở điểm cuối, tất cả sẽ sôi sục với hiệu suất cơ sở hạ tầng dịch vụ / máy chủ và môi trường máy khách sẽ tiêu thụ nó.