http HEAD so với GET hiệu suất

Tôi đang thiết lập một dịch vụ web REST chỉ cần trả lời CÓ hoặc KHÔNG, càng nhanh càng tốt.

Thiết kế một dịch vụ HEAD có vẻ là cách tốt nhất để làm điều đó nhưng tôi muốn biết liệu tôi có thực sự mất thời gian so với việc thực hiện yêu cầu GET hay không.

Tôi cho rằng tôi đạt được luồng nội dung không được mở / đóng trên máy chủ của mình (khoảng 1 mili giây?). Vì số lượng byte trả về rất thấp, tôi có mất thời gian trong quá trình truyền tải, ở số gói IP không?

Cảm ơn trước sự phản ứng của bạn!

Biên tập:

Để giải thích thêm về bối cảnh:

• Tôi có một tập hợp các dịch vụ REST đang thực thi một số quy trình, nếu chúng ở trạng thái hoạt động.
• Tôi có một dịch vụ REST khác cho biết trạng thái của tất cả các dịch vụ đầu tiên này.

Vì dịch vụ cuối cùng đó sẽ được gọi rất thường xuyên bởi một tập hợp rất lớn khách hàng (dự kiến ​​cứ sau 5ms sẽ có một cuộc gọi), tôi đã tự hỏi liệu sử dụng phương pháp HEAD có thể là một tối ưu hóa có giá trị không? Khoảng 250 ký tự được trả lại trong phần nội dung phản hồi. Phương pháp HEAD ít nhất đạt được sự vận chuyển của 250 ký tự này, nhưng tác động đó là gì?

Tôi đã cố gắng đánh giá sự khác biệt giữa hai phương pháp (HEAD so với GET), chạy 1000 lần các cuộc gọi, nhưng không thấy lợi ích gì cả (<1ms) ...

Một URI RESTful phải đại diện cho một "tài nguyên" tại máy chủ. Tài nguyên thường được lưu trữ dưới dạng bản ghi trong cơ sở dữ liệu hoặc tệp trên hệ thống tệp. Trừ khi tài nguyên lớn hoặc truy xuất chậm tại máy chủ, bạn có thể không thấy mức tăng có thể đo lường được bằng cách sử dụng HEADthay thế GET. Có thể là việc truy xuất dữ liệu meta không nhanh hơn việc truy xuất toàn bộ tài nguyên.

Bạn có thể triển khai cả hai tùy chọn và đánh giá chúng để xem cái nào nhanh hơn, nhưng thay vì tối ưu hóa vi mô, tôi sẽ tập trung vào việc thiết kế giao diện REST lý tưởng. Một API REST sạch thường có giá trị hơn về lâu dài so với một API nhỏ có thể nhanh hơn hoặc không nhanh hơn. Tôi không khuyến khích việc sử dụng HEAD, chỉ đề nghị bạn chỉ sử dụng nó nếu đó là thiết kế "phù hợp".

Nếu thông tin bạn thực sự cần là dữ liệu meta về một tài nguyên có thể được biểu diễn độc đáo trong tiêu đề HTTP hoặc để kiểm tra xem tài nguyên đó có tồn tại hay không, HEADcó thể hoạt động tốt hay không .

Ví dụ: giả sử bạn muốn kiểm tra xem tài nguyên 123 có tồn tại hay không. A 200nghĩa là "có" và a 404nghĩa là "không":

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

Tuy nhiên, nếu "có" hoặc "không" bạn muốn từ dịch vụ REST của mình là một phần của chính tài nguyên chứ không phải là dữ liệu meta, bạn nên sử dụng GET.

Tôi đã tìm thấy câu trả lời này khi tìm câu hỏi tương tự mà người yêu cầu đã hỏi. Tôi cũng tìm thấy cái này tại http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html :

Phương thức HEAD giống với GET ngoại trừ việc máy chủ KHÔNG PHẢI trả lại nội dung thư trong phản hồi. Thông tin siêu dữ liệu chứa trong các tiêu đề HTTP phản hồi yêu cầu HEAD NÊN giống với thông tin được gửi để phản hồi yêu cầu GET. Phương pháp này có thể được sử dụng để thu thập thông tin về thực thể được ám chỉ bởi yêu cầu mà không cần chuyển chính nội dung thực thể. Phương pháp này thường được sử dụng để kiểm tra các liên kết siêu văn bản về tính hợp lệ, khả năng truy cập và sửa đổi gần đây.

Đối với tôi, dường như câu trả lời chính xác cho câu hỏi của người yêu cầu là nó phụ thuộc vào những gì được biểu thị bởi giao thức REST. Ví dụ, trong trường hợp cụ thể của tôi, giao thức REST của tôi được sử dụng để truy xuất hình ảnh khá lớn (như hơn 10K). Nếu tôi có một số lượng lớn các tài nguyên như vậy được kiểm tra liên tục và cho rằng tôi sử dụng các tiêu đề yêu cầu, thì việc sử dụng yêu cầu HEAD sẽ rất hợp lý, theo khuyến nghị của w3.org.

Tôi thực sự không khuyến khích kiểu tiếp cận này.

Một dịch vụ RESTful phải tôn trọng ngữ nghĩa của động từ HTTP. Động từ GET có nghĩa là truy xuất nội dung của tài nguyên, trong khi động từ HEAD sẽ không trả về bất kỳ nội dung nào và có thể được sử dụng, chẳng hạn, để xem liệu tài nguyên có thay đổi hay không, để biết kích thước hoặc loại của nó, để kiểm tra xem nó có tồn tại, và như vậy.

Và hãy nhớ rằng: tối ưu hóa sớm là gốc rễ của mọi điều xấu.

Hiệu suất của bạn sẽ hầu như không thay đổi bằng cách sử dụng yêu cầu HEAD thay vì yêu cầu GET.

Hơn nữa, khi bạn muốn nó là REST-ful và bạn muốn NHẬN dữ liệu, bạn nên sử dụng yêu cầu GET thay vì yêu cầu HEAD.

GET tìm nạp đầu + nội dung, HEAD chỉ tìm nạp đầu. Nó không phải là một vấn đề quan điểm mà cái nào nhanh hơn. Tôi không phủ nhận các câu trả lời được ủng hộ ở trên. Nếu bạn đang tìm kiếm thông tin META thay vì tìm HEAD, điều này có nghĩa là cho mục đích này.

Tôi không hiểu mối quan tâm của bạn về 'luồng cơ thể đang mở / đóng'. Nội dung phản hồi sẽ ở trên cùng một luồng với tiêu đề phản hồi http và sẽ KHÔNG tạo kết nối thứ hai (nhân tiện, kết nối này nhiều hơn trong phạm vi 3-6ms).

Điều này có vẻ giống như một nỗ lực tối ưu hóa rất trước khi trưởng thành về một thứ gì đó sẽ không tạo ra sự khác biệt đáng kể hoặc thậm chí có thể đo lường được. Sự khác biệt thực sự là sự phù hợp với REST nói chung, khuyến nghị sử dụng GET để lấy dữ liệu ..

Câu trả lời của tôi là KHÔNG, hãy sử dụng GET nếu thấy hợp lý, không có hiệu suất tăng khi sử dụng HEAD.

Yêu cầu HEAD cũng giống như yêu cầu GET , ngoại trừ phần nội dung của phản hồi trống. Loại yêu cầu này có thể được sử dụng khi tất cả những gì bạn muốn là siêu dữ liệu về tệp nhưng không cần phải vận chuyển tất cả dữ liệu của tệp.

Bạn có thể dễ dàng thực hiện một bài kiểm tra nhỏ để tự mình đo lường hiệu suất. Tôi nghĩ rằng sự khác biệt về hiệu suất sẽ không thể bỏ qua, bởi vì nếu bạn chỉ trả về 'Y' hoặc 'N' trong nội dung, thì đó là một byte bổ sung duy nhất được thêm vào một luồng đã mở.

Tôi cũng muốn sử dụng GET vì nó đúng hơn. Bạn không phải trả lại nội dung trong tiêu đề HTTP, chỉ siêu dữ liệu.