REST API: пользовательские заголовки 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
76
http rest

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

87

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

5

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

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

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

GET/orders/view/client / 23

3

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

аутентификация: 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

также OK:

GET /orders/view/23 or

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

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

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

0