HTTP 엔티티는 정확히 무엇입니까?

누군가가 정확히 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)를 보여줍니다. 전체 체인을 이동하는 요청 또는 응답 메시지는 4 개의 개별 연결을 통과합니다.

• 메시지 또는 엔티티에 대한 헤더 필드

요청 및 응답 메시지 모두에 대해 일반적으로 적용 할 수 있지만 전송중인 엔티티 에는 적용되지 않는 헤더 필드가 몇 개 있습니다 . 이러한 헤더 필드 는 전송중인 메시지 에만 적용됩니다 .

• 메시지의 헤더 필드는 체인을 따라 변경 될 수 있습니다.

전송 인코딩은 메시지의 안전하고 적절한 전송을 보장하기 위해 애플리케이션에서 적용한 전송 코딩을 나타 내기 위해 사용되어야합니다. Transfer-Encoding은 엔터티가 아닌 메시지의 속성이므로 요청 / 응답 체인을 따라 모든 응용 프로그램에서 추가하거나 제거 할 수 있습니다.

• 메시지 본문과 엔터티 본문 간의 관계

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

여기서,은 Transfer-Encoding"청크"될 수있는 메시지를 전송하는 방법 및 수단 Content-Encoding엔티티를 압축하는 방법을 나타내며, "GZIP"일 수있다.

그것은이다 나타내는 추상화 요청 또는 응답 페이로드를 . 의 JavaDoc은 그 목적 및 다양한 개체 유형에 분명하다.

HTTPClient Entity이름은 HTTP Entity 에 따라 명명 된 것 같습니다 .

HTTP는 네트워크를 통해 원격 시스템에서 정보에 액세스 할 때 관찰되는 프로토콜입니다. 일반적으로 네트워크는 인터넷이고 원격 시스템은 서버입니다.

A로부터 B에게 정보를 요청할 때 그에게 메시지를 전합니다. (의뢰). 사람 B가 귀하에게 답장합니다 (응답). 요청 및 응답은 HTTP 메시지 유형입니다.

A는 정보를 요구하는 대신 B에게 무언가를하도록 요청할 수 있습니다. 사람 A는 사람 B가 안전한 위치에 파일을 저장하기를 원합니다. 그래서 사람 A는 그 파일 (HTTP Entity)을 사람 B에게 전달하고 그에게 무언가 (HTTP 메시지)를 요청합니다. 이 경우 Person은 "Entity"를 전달합니다. HTTP Entity의 컨텍스트에서 이는 메시지와 함께 첨부 된 페이로드입니다.

비유가 도움이 되었기를 바랍니다.

@ hawkeye-parker의 의견에서 말했듯이 Entity가 더 이상 사용되지 않는 것 같습니다. 화장 이 2014 RFC에서 검색을 , 당신은 HTTP를 엔티티에 대한 XML 엔티티 및 메시지 본문,하지만 아무것도에 대해 볼 수 있습니다.

그럼에도 불구하고 HttpClient뿐만 아니라 JaxRS 클라이언트에도 setEntity()and getEntity()메서드가 있습니다.

받아 들여진 대답을 고려할 때 두 라이브러리가 모두 잘못되었습니다! HttpClient.setEntity()이전에 설정된 헤더를 제거하지 않습니다.

HttpEntityRequest (헤더 포함)에서 전달할 내용과 응답에서 얻는 내용입니다. Get Request의 경우 간단한 문자열을 전달합니다.

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

Post의 경우 완전한 엔티티 클래스를 전달합니다.

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

엔티티는 메시지와 같은 것으로, 위치, 언어, 인코딩과 같은 메타 데이터가있는 헤더로 구성됩니다.

그리고 선택적으로 본문-헤더에 지정된대로 콘텐츠 형식이 지정됩니다.

여기에있는 좋은 답변 중 RFC 2616 (Hypertext Transfer Protocol-HTTP / 1.1) 에서 직접 가져온 것을 언급 할 가치가 있다고 생각합니다 .

실재

요청 및 응답 메시지는 요청 방법 또는 응답 상태 코드에 의해 달리 제한되지 않는 경우 엔터티를 전송할 수 있습니다. 엔티티는 엔티티 헤더 필드와 엔티티 본문으로 구성되지만 일부 응답에는 엔티티 헤더 만 포함됩니다.

단 한마디 : 엔티티가 전송 될 수 있고, 이는 일 수 헤더 +의 본체 , 또는 단지 헤더 .

위의 링크가 있기 때문에 추가 댓글을 작성하는 데 자신을 억 누릅니다.