HTTP 요청 헤더와 요청 본문에 속하는 것은 무엇입니까?

모바일 클라이언트를위한 일련의 웹 서비스를 개발 중이며 요구 사항에 따라 모든 요청에 ​​포함시키고 특정 요청에 저장하고 다른 결과를 필터링하는 데 사용되는 고유 한 장치 ID가 필요합니다.

모든 요청에 ​​포함되기 때문에 사용자 정의 HTTP 헤더에 넣을 것을 제안 했으므로 주어진 데이터가 헤더 또는 다른 데이터와 함께 있는지 여부를 결정하는 데 어떤 기준이 사용 될지 궁금해지기 시작했습니다. 요청 본문

그러한 기준이 있습니까?

정보가 중요하면 몸에 넣어야합니다.

왜?

1. 프록시 서버는 헤더를 수정할 수 있습니다. 많은 사람들이 모르는 헤더를 제거하도록 구성되어 있습니다. 그러나 이것은 암호화되지 않은 HTTP를 사용하는 경우에만 적용됩니다. HTTPS를 사용하면 프록시가 암호화되어 있으므로 헤더를 변경할 수 없습니다.
2. 웹 서비스를 사용할 때는 일반적으로 다른 장치, 서비스 및 도구와의 상호 운용성을 위해 사용합니다. 웹 서비스와 함께 작동하는 대부분의 API 및 도구는 요청을 쉽게 변경할 수 있지만 많은 경우 사용자 지정 헤더를 추가하기가 어렵거나 불가능합니다. 물론 이것은 상호 운용성이 중요한 경우에만 적용됩니다. 그러나 신경 쓰지 않을 때는 원시 TCP에서 자체 프로토콜을 구축하는 대신 웹 서비스를 사용하는 이유를 먼저 물어볼 수 있습니다.

선이 다소 흐릿한 반면 필자의 경험으로는 비즈니스 로직이 작동하는 데이터가 본문에 있어야하고 메타 데이터를 헤더에 넣을 수 있어야합니다.

그것을 보는 또 다른 방법은 특정 종류의 요청에만 나타나는 데이터가 본문에 있어야하고 전체 응용 프로그램에서 일관되게 처리되는 데이터는 헤더에 들어가야한다는 것입니다.

또 다른 관점은 다음과 같습니다. 예를 들어 응용 프로그램이 아닌 라우터 / 방화벽에 의해 데이터 조각이 전체적으로 처리된다고 상상할 수 있습니까? 그렇다면 본문이 아닌 헤더에 들어가야합니다.

이러한 규칙을 적용하는 몇 가지 예는 다음과 같습니다.

• 보안 자격 증명은 대부분의 경우 응용 프로그램의 모든 위치에서 동일하게 처리되므로 헤더로 이동합니다. 구현 레벨에서는 요청을 처리하는 실제 엔드 포인트와 상관없이 유효한 신임 정보없이 요청을 거부하는 일부 요청 필터가있을 수 있습니다.
• 반면에 관리자가 시스템에 사용자를 추가 할 수있는 엔드 포인트가있는 경우, 작성 될 사용자의 로그인은 다음과 같은 이유로 요청 본문에 있어야합니다. a) 애플리케이션의 비즈니스 로직에 의해 처리됩니다. b) 이 특정 엔드 포인트에는 나타나지만 다른 엔드 포인트에는 나타나지 않습니다.
• 캐싱을 제어하는 ​​옵션은 헤더에 잘 맞을 수 있습니다 (캐싱이 응용 프로그램 비즈니스 논리의 핵심 부분이 아닌 경우).

고유 한 장치 ID에 대한 질문으로 돌아가십시오. 예를 들어 로깅 전용으로 어디에서나 일관된 방식으로 사용되는 경우 헤더에 넣을 수 있습니다. 그러나 엔드 포인트에 따라 다른 방식으로 요청을 필터링하는 데 사용되는 경우 본문에있는 것이 좋습니다. 물론 두 가지 사용 사례가 모두 있다면 API 사용자가 동일한 데이터를 두 곳에 두도록 강요하는 것보다 한 가지 방법으로 (아마 헤더) 전달하는 것이 좋습니다. 일관되지 않은 입력 또는 어떤 종류의 검증 구현.

클라이언트 요청의 내용 동일한 서버에 대한 여러 요청에서 변경되지 않는 HEADER의 일부가됩니다 (예 : 자격 증명). 요청마다 자주 변경되는 다른 항목은 BODY의 일부입니다.

또는

메시지 / 본문 콘텐츠의 속성이 헤더로 이동합니다. 예) 인코딩 유형, 내용 길이, 내용 유형.

과

귀하의 경우 필터 매개 변수와 같은 URL에 쿼리 / 요청 매개 변수로 추가해야합니다.

/mobiles?type=MOTO&colour=black

편안한 서비스에서 URL 자체는 객체를 참조합니다

/conferences/{conference_id} -> 특정 회의를 나타냅니다