Передача параметров get запроса в url vs в headers?
Заметил, что RestApi можно реализовать как http(s)://hostname.com/path?param1=123¶m2=some_value
Но также и при формировании запроса ставить хэдэры, что в fetch или xhr.
В принципе, с точки зрения эстетичности я бы отдал предпочтение отправлять параметры в кастомных хедерах.
Но также и при формировании запроса ставить хэдэры, что в fetch или xhr.
В принципе, с точки зрения эстетичности я бы отдал предпочтение отправлять параметры в кастомных хедерах.
Есть ли вообще какие-то минусы/плюсы в таком подходе?
Помимо всего прочего, если писать свое Api то ту и документация будет выглядеть красивее и код у того, кто будет это Api использовать. Например, получить данные поста
1. const post = await fetch(/posts?post_id=151255)
2. const post = await fetch(/posts, {headers: {post_id: 151255}}) (да тут конечно может не очень красиво, но, когда параметров много, такой запрос проще формировать).
Помимо всего прочего, если писать свое Api то ту и документация будет выглядеть красивее и код у того, кто будет это Api использовать. Например, получить данные поста
1. const post = await fetch(/posts?post_id=151255)
2. const post = await fetch(/posts, {headers: {post_id: 151255}}) (да тут конечно может не очень красиво, но, когда параметров много, такой запрос проще формировать).
Единственное мне кажется есть проблема с кэширование запросов, где параметры в хедерах передаются?
ПрограммированиеИнтернет+2
Передать данные в запросе можно несколькими способами:
- Как часть адреса
- В query-параметрах адреса
- В кукис
- В кастомных http-хэдерах
- В теле запроса
В первом и втором случае параметры видны в адресе, что одновременно является и плюсом и минусом. Что выбрать — зависит от ваших целей. Например, адрес проще скопировать сразу со всеми параметрами, что может быть полезно для отладки. Если вы отправляете запрос через curl или из кода, то принципиальной разницы нет.
Никто не мешает вам передавать идентификатор сущности где хотите, просто это будет уже другой стиль, а не REST. В REST API традиционно принято соглашение, по которому адрес должен указывать на конкретную сущность. В хэдерах при этом может передаваться информация для аутентификации или настройки (например, часовой пояс), а в query-параметрах какие-то дополнительные параметры конкретного запроса, не указывающие непосредственно на сущность (например, режим сортировки или поисковая строка).
Примеры:
- /posts/123/ - адрес сущности с id=123
- /posts - адрес списка сущностей
- /posts?sort=asc - всё ещё REST, список сущностей с опционной сортировкой
- /posts - внезапно не список, а конкретная сущность, id которой передается в хэдерах, не REST
Ещё один аргумент, почему id должна быть рядом с адресом — стремление к большей связности (cohesion). Если мы где-то указываем id сущности, то любой вменяемый разработчик ожидает увидеть там же и её тип. А тут получается у нас тип указан в урле (/posts) а id внезапно надо искать в хэдере. Это станет лишним усложнением при отладке кода.
2 эксперта согласны
Александр Кузнецов
5 нояб 2021подтверждает
Да, всё верно