Почему мы предпочитаем, чтобы заголовок авторизации отправлял токен-носитель на сервер другим методам, таким как кодирование URL

Почему заголовок авторизации в основном используется для отправки токена-носителя на сервер? Почему бы нам не отправить токен авторизации в качестве параметра URL или не опубликовать его как полезную нагрузку json с телом запроса?


rest authorization access-token bearer-token oauth
person ivplay    schedule 01.12.2016    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Заголовки идеально подходят для хранения этих данных, они не зависят от типа запроса.

Вы можете отправить токен авторизации в теле, даже все остальное, например Content-Type, Content-Length, заголовки кеша, но разные типы запросов (_3 _, _ 4_ ..) могут иметь другой формат тела запроса. GET отправляет данные с использованием query parameters _7 _ / _ 8_ в закодированной форме в теле (с Content-Type: application/x-www-form-urlencoded, чтобы сервер знал о формате входящих данных), Content-Type: application/json с JSON в теле, XML и т. Д. С многостраничными запросами все становится сложнее (проверьте это https://stackoverflow.com/a/19712083/1017363).

Как видите, токен авторизации в теле или запросе усложняет задачу на стороне клиента и сервера. Клиент должен знать, как «подогнать» токен авторизации к каждому запросу, а сервер должен знать, как читать это значение.

person PiKey    schedule 01.12.2016