Зачем использовать заголовки HTTP, а не что-то в теле запроса?
Сохраняя ваши данные аутентификации отдельно от полезной нагрузки (данных, которые вы передаете), вы облегчаете обработку аутентификации на более ранней стадии в конвейере запросов. Например, сервер-привратник может принимать запросы и аутентифицировать их, просматривая только заголовки, а затем передавать их модулю / серверу / классу, который анализирует тело запроса и выполняет реальную работу.
Если запрос не проходит аутентификацию, он может быть отклонен, прежде чем он даже приблизится к коду, имеющему дело с деньгами.
Конечно, вы можете спроектировать свою систему таким образом, несмотря ни на что, но сохранение ее в заголовках означает, что вам не нужно анализировать тело запроса или даже просматривать его. Вам также не нужно беспокоиться о настройке Content-Length:, если вы хотите изменить заголовки перед передачей их на другой сервер.
Зачем использовать пользовательские заголовки HTTP, а не WWW-Authenticate или Cookie?
Я думаю, это просто потому, что PayPal хочет иметь более надежную схему, чем любая из них. WWW-Authenticate допускает только базовую (в открытом виде) и дайджест-аутентификацию (MD5), и с тех пор, как была написана спецификация для них, было разработано много лучших схем. Они также не допускают более имени пользователя и пароля.
Cookies - это технически непрозрачные биты данных, которые вы получаете с сервера и передаете обратно без изменений. Опять же, они могли бы рассказать вам, как генерировать информацию, которую вы передаете в заголовке Cookie, но на самом деле это не соответствовало бы спецификации, поэтому на этом этапе, почему бы просто не использовать некоторые пользовательские заголовки?