Ai đó vui lòng mô tả cho tôi chính xác thực thể HTTP là gì?
Tôi đang đọc tài liệu HTTPClient, nhưng tôi không thực sự hiểu điều đó có nghĩa là gì?
Ai đó vui lòng mô tả cho tôi chính xác thực thể HTTP là gì?
Tôi đang đọc tài liệu HTTPClient, nhưng tôi không thực sự hiểu điều đó có nghĩa là gì?
Câu trả lời:
Một thực thể HTTP là phần lớn các yêu cầu HTTP hoặc phản ứng, bao gồm một số các tiêu đề và cơ thể, nếu có. Nó dường như là toàn bộ yêu cầu hoặc phản hồi mà không có yêu cầu hoặc dòng trạng thái (mặc dù chỉ một số trường tiêu đề nhất định được coi là một phần của thực thể ).
Để minh họa; đây là một yêu cầu:
POST /foo HTTP/1.1 # Not part of the entity.
Content-Type: text/plain # ┬ The entity is from this line down...
Content-Length: 1234 # │
# │
Hello, World! ... # ┘
Và một phản hồi:
HTTP/1.1 200 OK # Not part of the entity.
Content-Length: 438 # ┬ The entity is from this line down...
Content-Type: text/plain # │
# │
Response body ... # ┘
&
thay vì &
. Đó không phải là một thực thể quá? Có gì khác biệt?
Dưới đây là 3 trường hợp đơn giản:
Trường hợp 1. Bạn đang tải lên 3 tệp trong một yêu cầu. 3 tệp đó là 3 thực thể. Mỗi người trong số họ có riêng Content-Type
để cho biết đó là loại tệp nào.
Trường hợp 2. Bạn đang xem một trang web. Trình duyệt đã tải xuống một tệp html dưới dạng thực thể trong nền. Vì trang có thể được cập nhật liên tục, bạn có thể nhận được một thực thể hoàn toàn khác sau này.
Trường hợp 3. Bạn có một 304 Not Modified
. Không có thực thể nào đã được chuyển giao.
Nói một cách dễ hiểu, Thực thể là một trọng tải tùy chọn bên trong thông báo http (yêu cầu hoặc phản hồi), vì vậy nó là mối quan hệ " một phần toàn bộ " giữa Thực thể và Thông báo.
Một số trường tiêu đề áp dụng Message
như Transfer-Encoding
mô tả cách chuyển thông điệp giữa các bên trung gian, và do đó CÓ THỂ được thêm vào hoặc loại bỏ bởi bất kỳ ứng dụng nào dọc theo chuỗi yêu cầu / phản hồi ( hop-by-hop headers
). So sánh, các trường tiêu đề đó áp dụng cho Entity
một số thuộc tính, mô tả kích thước, loại, thuật toán nén của thực thể, v.v.
Đọc thêm, trích dẫn từ RFC 2616 phần 1.4, 4.5 và 4.3:
request chain --------------------------------------> UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------- response chain
Hình trên cho thấy ba trung gian (A, B và C) giữa tác nhân người dùng và máy chủ gốc. Một thông báo yêu cầu hoặc phản hồi đi qua toàn bộ chuỗi sẽ đi qua bốn kết nối riêng biệt.
Có một số trường tiêu đề có khả năng áp dụng chung cho cả thông báo yêu cầu và phản hồi, nhưng không áp dụng cho thực thể đang được chuyển . Các trường tiêu đề này chỉ áp dụng cho thông báo đang được truyền đi .
Mã hóa chuyển giao PHẢI được sử dụng để chỉ ra bất kỳ mã hóa chuyển giao nào được ứng dụng áp dụng để đảm bảo chuyển thông điệp an toàn và đúng cách. Mã hóa truyền là một thuộc tính của thông điệp, không phải của thực thể, và do đó CÓ THỂ được thêm vào hoặc xóa bởi bất kỳ ứng dụng nào dọc theo chuỗi yêu cầu / phản hồi.
message-body = Transfer-Encoding( Content-Encoding(entity-body) )
nơi Transfer-Encoding
có thể là "chunked" có nghĩa là cách chuyển thông điệp và Content-Encoding
có thể là "gzip" là viết tắt của cách nén thực thể.
HTTP là một Giao thức được quan sát khi truy cập thông tin từ một máy từ xa thông qua mạng. Thông thường mạng là internet và máy từ xa là máy chủ.
Khi bạn hỏi thông tin từ người A đến người B, bạn đã đưa cho anh ta một thông điệp. (Yêu cầu). Người B trả lời bạn (Hồi đáp). Yêu cầu và phản hồi là các loại thông báo HTTP.
Người A có thể yêu cầu Người B làm một việc gì đó, thay vì hỏi thông tin. Giả sử, Người A muốn Người B lưu trữ một tệp ở một vị trí an toàn. Vì vậy, Người A chuyển tệp đó (Thực thể HTTP) cho Người B và yêu cầu anh ta làm điều gì đó (Thông báo HTTP). Trong trường hợp này, Person đang chuyển một "Thực thể". Trong ngữ cảnh của Thực thể HTTP, nó là một trọng tải được đính kèm với thông báo.
Hy vọng sự tương tự đã giúp.
Như đã nói trong một bình luận của @ hawkeye-parker, có vẻ như Entity đã không còn được dùng nữa. Thực hiện tìm kiếm trong rfc 2014 này , và bạn sẽ thấy về các thực thể XML và nội dung thư, nhưng không có gì về thực thể Http.
Tuy nhiên, HttpClient, cũng như ứng dụng khách JaxRS, có một setEntity()
và getEntity()
phương pháp.
Xem xét câu trả lời được chấp nhận, cả hai thư viện đều sai! HttpClient.setEntity()
sẽ không xóa các tiêu đề đã đặt trước đó.
HttpEntity
là những gì bạn sẽ chuyển trong Yêu cầu (có tiêu đề) và những gì bạn nhận được trong Phản hồi. Đối với Nhận Yêu cầu, chúng tôi đang chuyển chuỗi đơn giản
HttpHeaders headers = new HttpHeaders();
headers.setAccept(Arrays.asList(MediaType.APPLICATION_JSON));
HttpEntity<String> entity = new HttpEntity<String>(headers);
Đối với bài đăng Chúng tôi sẽ vượt qua Lớp thực thể hoàn chỉnh
public String createProducts(@RequestBody Product product) {
HttpHeaders headers = new HttpHeaders();
headers.setAccept(Arrays.asList(MediaType.APPLICATION_JSON));
HttpEntity<Product> entity = new HttpEntity<Product>(product,headers);
return restTemplate.exchange(
"http://localhost:8080/products", HttpMethod.POST, entity, String.class
).getBody();
}
Thực thể là một cái gì đó giống như một thông điệp, nó bao gồm tiêu đề, nơi chứa siêu dữ liệu như vị trí, ngôn ngữ, mã hóa ...
Và tùy chọn của một nội dung - nội dung đó được định dạng, v.v. như được chỉ định trong tiêu đề
Trong số các câu trả lời tốt mà chúng tôi có ở đây, tôi tin rằng điều đáng nói là một thứ đến trực tiếp từ RFC 2616 (Giao thức truyền siêu văn bản - HTTP / 1.1) :
Thực thể
Thông báo Yêu cầu và Phản hồi CÓ THỂ chuyển một thực thể nếu không bị hạn chế bởi phương thức yêu cầu hoặc mã trạng thái phản hồi. Một thực thể bao gồm các trường tiêu đề thực thể và một phần thân thực thể, mặc dù một số phản hồi sẽ chỉ bao gồm các tiêu đề thực thể.
Trong aa Tóm lại: một thực thể có thể được chuyển giao, và nó có thể là tiêu đề + cơ thể , hay chỉ là tiêu đề .
Vì có liên kết ở trên, tôi tự giữ mình trong việc đưa ra các nhận xét bổ sung.