Chociaż linia jest nieco rozmyta, dla mnie ogólna zasada brzmi: dane, na których działa logika biznesowa, powinny znajdować się w ciele, metadane mogą / powinny być umieszczone w nagłówkach.
Innym sposobem patrzenia na to jest: dane, które pojawiają się tylko w określonych rodzajach żądań, powinny znajdować się w ciele, podczas gdy dane, które są przetwarzane konsekwentnie w całej aplikacji, powinny znajdować się w nagłówkach.
Jeszcze inny punkt widzenia: czy możesz sobie wyobrazić, że część danych jest przetwarzana globalnie, np. Przez router / zaporę ogniową, a nie przez twoją aplikację? Jeśli tak, to prawdopodobnie powinien on znajdować się w nagłówkach, a nie w treści.
Oto niektóre przykłady zastosowania tych reguł:
- Poświadczenia bezpieczeństwa przechodzą w nagłówki, ponieważ najprawdopodobniej będą obsługiwane tak samo we wszystkich miejscach aplikacji; na poziomie implementacji prawdopodobnie pojawi się filtr odrzucający żądania bez prawidłowych poświadczeń, niezależnie od faktycznego punktu końcowego obsługującego żądanie, na wypadek, gdyby przeszedł przez filtr.
- Jeśli z drugiej strony masz punkt końcowy, który pozwala administratorowi dodawać użytkowników do systemu, login użytkownika, który ma zostać utworzony, powinien znajdować się w treści żądania, ponieważ: a) jest obsługiwany przez logikę biznesową aplikacji, b) pojawia się w tym konkretnym punkcie końcowym, ale nie w innych.
- Opcje kontrolujące buforowanie mogą dobrze pasować do nagłówków (chyba że buforowanie jest podstawową częścią logiki biznesowej aplikacji).
Wracając do pytania dotyczącego unikalnego identyfikatora urządzenia: jeśli jest używane wszędzie w spójny sposób, np. Tylko do logowania, można je umieścić w nagłówkach. Ale jeśli jest używany do filtrowania żądań na różne sposoby w zależności od punktu końcowego, lepiej byłoby w ciele. Oczywiście, jeśli masz oba przypadki użycia, prawdopodobnie lepiej jest trzymać się tylko jednego sposobu przekazywania (prawdopodobnie nagłówków), niż zmuszać użytkownika interfejsu API do umieszczania tych samych danych w dwóch miejscach, co daje dylemat: niespójne dane wejściowe lub wdrożenie pewnego rodzaju walidacji.