Điều gì thuộc về một tiêu đề yêu cầu HTTP so với cơ thể yêu cầu?


51

Tôi đang làm việc trên một tập hợp các dịch vụ web cho máy khách di động và các yêu cầu yêu cầu một id thiết bị duy nhất được bao gồm trong tất cả các yêu cầu, được lưu trữ trong một số yêu cầu nhất định và được sử dụng để lọc kết quả trong các yêu cầu khác.

Một đề xuất đã được đưa ra rằng nó được đặt trong một tiêu đề HTTP tùy chỉnh vì nó sẽ được bao gồm trong tất cả các yêu cầu, vì vậy tôi bắt đầu tự hỏi những tiêu chí nào có thể được sử dụng để xác định xem một phần dữ liệu nhất định có thuộc một tiêu đề hay cùng với dữ liệu khác trong cơ quan yêu cầu.

Có tiêu chí nào như vậy không?


Câu trả lời:


51

Khi thông tin quan trọng, bạn nên đưa nó vào cơ thể.

Tại sao?

  1. máy chủ proxy được phép sửa đổi các tiêu đề. Nhiều người được cấu hình để loại bỏ bất kỳ tiêu đề nào họ không biết. Tuy nhiên, điều này chỉ áp dụng khi bạn sử dụng HTTP không được mã hóa. Khi bạn sử dụng HTTPS, proxy không thể thay đổi các tiêu đề vì chúng được mã hóa.
  2. Khi bạn sử dụng dịch vụ web, bạn thường làm như vậy để có khả năng tương tác với các thiết bị, dịch vụ và công cụ khác. Hầu hết các API và công cụ hoạt động với dịch vụ web có thể dễ dàng thay đổi yêu cầu, nhưng nhiều công cụ gây khó khăn hoặc thậm chí không thể thêm tiêu đề tùy chỉnh. Điều này, tất nhiên, chỉ áp dụng khi khả năng tương tác là một mối quan tâm. Nhưng khi bạn không quan tâm, bạn có thể muốn tự hỏi tại sao bạn lại sử dụng dịch vụ web ngay từ đầu thay vì chỉ xây dựng giao thức của riêng bạn trên TCP thô.

TRẢ LỜI TUYỆT VỜI - hai cân nhắc có ý nghĩa với tôi nhưng tôi chưa được dạy trước đây.
R Claven

1
IK này đã cũ nhưng tôi đã tham gia cộng đồng này chỉ để nâng cao câu trả lời này. Thanh danh.
Kali Ion

22

Mặc dù dòng này hơi mờ, nhưng đối với tôi, một nguyên tắc nhỏ là: dữ liệu mà logic kinh doanh của bạn hoạt động phải nằm trong phần thân, siêu dữ liệu có thể / nên được đặt trong các tiêu đề.

Một cách khác để xem xét nó là: dữ liệu chỉ xuất hiện trong các loại yêu cầu cụ thể phải có trong cơ thể trong khi dữ liệu được xử lý nhất quán trên toàn bộ ứng dụng sẽ đi vào tiêu đề.

Tuy nhiên, một quan điểm khác là: bạn có thể tưởng tượng rằng một phần dữ liệu được xử lý trên toàn cầu, ví dụ như bởi bộ định tuyến / tường lửa thay vì ứng dụng của bạn không? Nếu có, nó có lẽ nên đi trong tiêu đề hơn là trong cơ thể.

Một số ví dụ về việc áp dụng các quy tắc này sẽ là:

  • Thông tin bảo mật đi vào các tiêu đề vì hầu hết có thể chúng sẽ được xử lý giống nhau ở tất cả các nơi của một ứng dụng; ở cấp độ triển khai, có thể sẽ có một số bộ lọc yêu cầu từ chối các yêu cầu mà không có thông tin xác thực hợp lệ bất kể điểm cuối thực tế xử lý yêu cầu trong trường hợp nó có được thông qua bộ lọc.
  • Mặt khác, nếu bạn có một điểm cuối cho phép quản trị viên thêm người dùng vào hệ thống của bạn, thì thông tin đăng nhập của người dùng sẽ được tạo trong cơ thể yêu cầu vì: a) nó được xử lý bởi logic nghiệp vụ của ứng dụng của bạn, b) nó xuất hiện ở điểm cuối cụ thể này nhưng không xuất hiện ở những điểm khác.
  • Các tùy chọn kiểm soát bộ nhớ đệm có thể phù hợp với các tiêu đề (trừ khi bộ đệm là một phần cốt lõi trong logic nghiệp vụ của ứng dụng của bạn).

Quay trở lại câu hỏi của bạn về ID thiết bị duy nhất: nếu nó được sử dụng một cách nhất quán ở mọi nơi, ví dụ như chỉ để đăng nhập, nó có thể được đặt trong tiêu đề. Nhưng nếu nó được sử dụng để lọc các yêu cầu theo các cách khác nhau tùy thuộc vào điểm cuối, nó sẽ tốt hơn trong cơ thể. Tất nhiên, nếu bạn có cả hai trường hợp sử dụng, có lẽ tốt hơn là chỉ sử dụng một cách duy nhất để vượt qua nó (có thể là các tiêu đề) thay vì buộc người dùng API phải đặt cùng một dữ liệu ở hai vị trí, cho phép bạn tiến thoái lưỡng nan khi cho phép đầu vào không nhất quán hoặc thực hiện một số loại xác nhận.


0

Nội dung của yêu cầu khách hàng; sẽ không được thay đổi trên nhiều yêu cầu cho cùng một máy chủ sẽ là một phần của HEADER, ví dụ như thông tin đăng nhập, những yêu cầu khác thường xuyên thay đổi theo yêu cầu sẽ là một phần của BODY.

HOẶC LÀ

thuộc tính của nội dung thư / nội dung sẽ đi vào tiêu đề. ví dụ) loại mã hóa, độ dài nội dung, loại nội dung.

Trong trường hợp của bạn, như các tham số bộ lọc nên được thêm dưới dạng tham số truy vấn / yêu cầu trong url.

/mobiles?type=MOTO&colour=black

Trong các dịch vụ nghỉ ngơi, url sẽ chỉ đến một đối tượng

/conferences/{conference_id} -> đề cập đến hội nghị cụ thể


Đây có phải là một trích dẫn? Từ đâu ? Tại sao bạn đề nghị điều này? Vui lòng thực hiện một số chỉnh sửa trong câu trả lời của bạn, để làm cho nó tốt hơn.
Machado
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.