http HEAD with GET performance

Question

Tôi đang thiết lập dịch vụ web REST chỉ cần trả lời CÓ hoặc KHÔNG, nhanh nhất có thể.

Thiết kế 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ự đạt được một chút thời gian so với thực hiện yêu cầu GET hay không.

Tôi cho rằng tôi có được luồng cơ thể không được mở/đóng trên máy chủ của tôi (khoảng 1 mili giây?). Vì số lượng byte trả lại rất thấp, tôi có thu được bất kỳ thời gian nào trong việc vận chuyển, trong số gói IP không?

Cảm ơn bạn đã trả lời!

Edit:

Để giải thích rõ hơn bối cảnh:

• tôi có một tập hợp các dịch vụ REST thực hiện một số quy trình, nếu họ đang ở trong 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 nhóm khách hàng lớn (một cuộc gọi dự kiến ​​mỗi 5ms), tôi đã tự hỏi nế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ả về trong phần trả lờ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 để benchmark sự khác biệt giữa hai phương pháp (HEAD vs GET), chạy 1000 lần các cuộc gọi, nhưng thấy không có lợi chút nào (< 1ms) ...

Answer 1

Một RESTful URI nên đại diện cho một "tài nguyên" tại máy chủ. Tài nguyên thường được lưu 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 các nguồn tài nguyên là lớn hay là chậm chạp trong việc lấy tại máy chủ, bạn có thể không nhìn thấy một lợi thể đo lường được bằng cách sử dụng HEAD thay vì GET. Có thể lấy dữ liệu meta không nhanh hơn việc lấy toàn bộ tài nguyên.

Bạn có thể thực hiện cả hai lựa chọn và chuẩn họ để xem đó là nhanh hơn, nhưng thay vì micro-tối ưu hóa, 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 trong thời gian dài hơn một API kludgey có thể có hoặc không có thể nhanh hơn được. Tôi không ngăn cản việc sử dụng HEAD, chỉ gợi ý rằng bạn chỉ sử dụng nó nếu đó là thiết kế "đúng".

Nếu thông tin bạn cần thực sự là dữ liệu meta về tài nguyên có thể được thể hiệ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, HEAD có thể hoạt động tốt.

Ví dụ: giả sử bạn muốn kiểm tra xem tài nguyên 123 có tồn tại không. Một 200 có nghĩa là "có" và một 404 có nghĩ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" mà bạn muốn từ dịch vụ REST bạn là một phần của tài nguyên riêng của mình, chứ không phải là dữ liệu meta , bạn nên sử dụng GET.

Answer 2

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.

Ngoài ra khi bạn muốn nó là REST-ful và bạn muốn GET dữ liệu, bạn nên sử dụng yêu cầu GET thay vì yêu cầu HEAD.

Answer 3

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

Tôi cũng sẽ đi với GET vì nó chính xác hơn. Bạn không được phép trả lại nội dung trong tiêu đề HTTP, chỉ siêu dữ liệu.

Answer 4

Tôi không hiểu mối lo ngại của bạn về 'luồng cơ thể đang được mở/đóng'. Cơ thể 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 (mà theo cách này là nhiều hơn trong phạm vi 3-6ms).

Điều này có vẻ như một nỗ lực tối ưu hóa 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, đề xuất sử dụng GET để lấy dữ liệu ..

Câu trả lời của tôi là KHÔNG, sử dụng GET nếu có ý nghĩa, không đạt được hiệu suất sử dụng HEAD.

Answer 5

Tôi mạnh mẽ không khuyến khích phương pháp tiếp cận này.

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

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

Answer 6

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

Phương thức HEAD giống hệt GET ngoại trừ máy chủ KHÔNG PHẢI trả lại nội dung thư trong phản hồi. Các metainformation chứa trong các tiêu đề HTTP để đáp ứng với một yêu cầu HEAD NÊN được giống hệt với thông tin được gửi để đáp ứng với một 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 ngụ ý bởi yêu cầu mà không cần chuyển giao thân 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 để có hiệu lực, khả năng truy cập và sửa đổi gần đây.

Dường như với tôi câu trả lời đúng cho câu hỏi của người yêu cầu là nó phụ thuộc vào những gì được đại diện 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 để lấy các hình ảnh khá lớn (như trong 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 trên cơ sở không đổi và cho rằng tôi sử dụng các tiêu đề yêu cầu, thì sẽ có ý nghĩa khi sử dụng yêu cầu HEAD, theo đề xuất của w3.org.

Answer 7

Tìm nạp đầu + phần thân, HEAD chỉ tìm nạp đầu. Nó không phải là một vấn đề của ý kiến ​​mà một trong những là nhanh hơn. Tôi không undestand các câu trả lời upvoted ở trên. Nếu bạn đang tìm kiếm thông tin META hơn là đi cho HEAD, đó là có nghĩa là cho mục đích này.