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.