API REST: пользовательские заголовки HTTP и параметры URL

когда вы используете пользовательские заголовки HTTP в части запроса REST API ?

пример:

вы когда-нибудь использовать 

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

вместо

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23
8 76
http database-restore

8 ответов:

URL указывает на сам ресурс. "Клиент" - это ресурс, на который можно действовать, поэтому он должен быть частью базового url:/orders/view/client/23.

параметры-это просто, чтобы параметризовать доступ к ресурсу. Это особенно вступает в игру с сообщениями и поисками:/orders/find?q=blahblah&sort=foo. Есть тонкая грань между параметрами и суб-ресурсов: /orders/view/client/23/active versus /orders/view/client/23?show=active. Я рекомендую стиль субресурса и параметры резервирования для поиска.

так как каждая конечная точка представляет состояние Передача (чтобы исказить мнемонику), пользовательские заголовки должны использоваться только для вещей, которые не включают имя ресурса (url), состояние ресурса (тело) или параметры, непосредственно влияющие на ресурс (параметры). Это оставляет истинные метаданные о запросе пользовательских заголовков.

HTTP имеет очень широкий выбор заголовков, которые охватывают почти все, что вам нужно. Где я видел, что пользовательские заголовки появляются в системе для системного запроса, работающего от имени a пользователь. Прокси-система проверит пользователя и добавит "X-User: userid " к заголовкам и использовать учетные данные системы, чтобы попасть в конечную точку. Получающая система проверяет, что учетные данные системы имеют право действовать от имени пользователя, а затем проверяет, что пользователь имеет право выполнять это действие.

87

Я бы использовал только пользовательский заголовок, когда нет другого способа передать информацию по стандарту или соглашению. Darren102 объясняет типичный способ передачи этого значения. Ваш Api будет гораздо более дружелюбным, используя типичные шаблоны стиха с использованием пользовательских заголовков.Это не значит, что у вас не будет случая использовать их, просто они должны быть последним средством и что-то еще не обработано спецификацией HTTP.

5

пользовательские заголовки имеют следующие преимущества:

  • можно легко читать с помощью сетевых инструментов / скриптов (аутентификация, мета-информация, ...)
  • сохраняет URL-адреса свободными от материалов безопасности (безопаснее, а не в кэшах браузера/прокси)
  • сохраняет URL-адреса чище: позволяет лучше кэшировать ресурсы
4

Я бы не использовал пользовательские заголовки, поскольку вы не знаете, будут ли какие-либо прокси передавать их. URL на основе это путь.

GET / orders / view / client / 23

3

когда вы используете...Заголовки HTTP в части запроса REST API?

аутентификация: GUID, обычная аутентификация, пользовательские токены и т. д. например., обычная проверка подлинности с помощью маркера Guid для REST api вместо имени пользователя / пароля

Если вы участвуете в передаче токенов или другой аутентификационной информации между доменами, охватываемыми PCI-DSS или другими правилами безопасности, вам также может потребоваться похоронить параметры, потому что некоторые правила явно требуют, чтобы элементы аутентификации оставались вне URL-адресов, которые могут быть тривиально воспроизведены (из истории браузера, журналов прокси и т. д.).

3

нет стандарта для отдыха, однако принятый способ будет 

GET /orders/view/23

не используя пользовательские заголовки и, следовательно, 23 после просмотра предполагает, что идентификатор, следовательно, у вас будет функция, которая принимает идентификатор и, следовательно, производит только эту информацию.

2

определенно хорошо:

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

тоже ОК:

GET /orders/view/23 or

Я думаю, что это тоже было бы хорошо:

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23
1

вы можете использовать пользовательские заголовки, чтобы включить дополнительную информацию о частично обработанном запросе, учитывая, что обволакивающим это не хорошая практика. Заголовкибезопасное.

0