Що саме являє собою HTTP Entity?

Хто-небудь, будь ласка, описав мені, що саме являє собою HTTP-сутність ?

Я читаю документацію HTTPClient, але я не дуже розумію, що це означає?

HTTP - суб'єкт є більшість із запиту HTTP або відповідь, що складається з деяких з заголовків і тіла, якщо вони присутні. Здається, це весь запит чи відповідь без запиту чи рядка стану (хоча лише певні поля заголовка вважаються частиною сутності ).

Проілюструвати; ось запит:

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! ...           # ┘

І відповідь:

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 ...           # ┘

Ось 3 прості випадки:

Випадок 1. Ви завантажуєте 3 файли в одному запиті. Ці 3 файли - це 3 об'єкти. У кожного з них є власне, Content-Typeщоб вказати, що це за файл.

Випадок 2. Ви переглядаєте веб-сторінку. Браузер завантажив файл HTML як сутність у фоновому режимі. Оскільки сторінку можна постійно оновлювати, пізніше ви можете отримати зовсім іншу суть.

Випадок 3. У вас є 304 Not Modified. Жодна організація не перенесена.

Словом, Entity - це необов'язкове корисне навантаження всередині http-повідомлення (або запит, або відповідь), тому це відношення " частина-ціле " між Entity та Message.

Деякі поля заголовка належать до Messageхотів Transfer-Encodingописати , як передати сполучення між посередниками і , таким чином , можуть бути додані або видалені будь-яким додатком уздовж ланцюжка запиту / відповіді ( hop-by-hop headers). Для порівняння, ці поля заголовка застосовуються до Entityдеяких властивостей, які описують розмір, тип сутності, алгоритм стиснення тощо ...

Подальше читання, цитуючи з RFC 2616 розділи 1.4, 4.5 та 4.3:

• Ланцюг запитів / відповідей

     request chain -------------------------------------->
   UA -----v----- A -----v----- B -----v----- C -----v----- O
      <------------------------------------- response chain

На малюнку вище показано три посередники (A, B і C) між користувальницьким агентом та сервером походження. Повідомлення про запит або відповідь, яке об’їжджає весь ланцюг, пройде через чотири окремих з'єднання.

• Поля заголовка для повідомлення або особи

Є кілька полів заголовків, які мають загальну застосовність як для запиту, так і для відповідей, але вони не стосуються суб'єкта, що передається . Ці поля заголовка стосуються лише переданого повідомлення .

• Поля заголовка для повідомлення можна змінювати по ланцюгу

Передача-кодування ОБОВ'ЯЗКОВО використовуватись для вказівки будь-яких кодувань передачі, застосованих програмою для забезпечення безпечної та належної передачі повідомлення. Перенесення-кодування - це властивість повідомлення, а не сутності, і таким чином МОЖЕ бути додано або видалено будь-якою програмою по ланцюгу запитів / відповідей.

• Зв'язок між тілом повідомлення та тілом сутності

message-body = Transfer-Encoding( Content-Encoding(entity-body) )

де Transfer-Encodingможе бути "зведено", що означає, як передавати повідомлення, а Content-Encodingможе бути "gzip", який означає, як стиснути сутність.

Це абстракція, що представляє корисне навантаження або відповідь . JavaDoc ясно на своїй цілі і різні типи сутностей.

Я думаю, що HTTPClient Entityназваний відповідно до HTTP Entity .

HTTP - це протокол, який спостерігається під час доступу до інформації з віддаленої машини через мережу. Зазвичай мережа - це Інтернет, а віддалена машина - сервер.

Коли ви запитуєте інформацію від людини А до людини Б, ви даєте йому повідомлення. (Запит). Особа B відповідає вам (Відповідь). Запит та відповідь - це типи повідомлень HTTP.

Особа A може попросити Особу B зробити щось, а не просити інформацію. Скажімо, особа A хоче, щоб особа B зберігала файл у захищеному місці. Отже, особа A передає цей файл (HTTP Entity) особі B і просить його щось зробити (повідомлення HTTP). У цьому випадку Особа проходить "Сутність". У контексті HTTP Entity це корисне навантаження, додане до повідомлення.

Сподіваюся, аналогія допомогла.

Як сказано в коментарі @ hawkeye-parker, схоже, що Entity була застаріла. Здійсніть пошук у цьому rfc 2014 року , і ви побачите про сутності XML та тіло повідомлень, але нічого про сутність Http.

Тим не менш, HttpClient, але і клієнт JaxRS, мають setEntity()і getEntity()метод.

Враховуючи прийняту відповідь, обидві бібліотеки помиляються! HttpClient.setEntity()не буде видалено раніше встановлені заголовки.

HttpEntityце те, що ви збираєтеся передати у запиті (із заголовком) та що отримуєте у відповіді. Для отримання запиту ми передаємо просту рядок

 HttpHeaders headers = new HttpHeaders();
 headers.setAccept(Arrays.asList(MediaType.APPLICATION_JSON));
 HttpEntity<String> entity = new HttpEntity<String>(headers);

Для пошти ми проходимо повний клас особи

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

Entity - це щось на зразок повідомлення, воно складається із заголовка, де є такі метадані, як розташування, lang, кодування ...

І необов'язково тіла - його вміст формується тощо, як зазначено в заголовку

Серед хороших відповідей, які ми маємо тут, я вважаю, що варто згадати те, що надходить безпосередньо з RFC 2616 (протокол передачі гіпертексту - HTTP / 1.1) :

Суб'єкт

Повідомлення із запитом та відповіддю МОЖЕ передати об'єкт, якщо інше не обмежено способом запиту чи кодом статусу відповіді. Суб'єкт складається з полів заголовка сутності та тіла сутності, хоча деякі відповіді включатимуть лише заголовки сутності.

Коротше кажучи: сутність може бути передана, і це може бути заголовок + тіло або просто заголовок .

Оскільки це посилання вище, я затримуюсь над тим, щоб робити додаткові коментарі.