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

Question

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

Пример:

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

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

вместо * 1008?*

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

Answer 1

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

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

Так как каждая конечная точка RE представляет State Transfer (для искажения мнемоники), пользовательские заголовки следует использовать только для вещей, которые не включают имя ресурса (URL), состояние ресурса (тело), или параметры, непосредственно влияющие на ресурс (параметры). Это оставляет истинные метаданные о запросе пользовательских заголовков.

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

Определенно ОК:

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

Answer 6

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

GET / заказы / просмотр / клиент / 23

Answer 7

Стандарт REST не существует, однако принятый способ будет

GET /orders/view/23

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

Answer 8

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