что такое гет параметры
Методы GET и POST. Использование и отличия
HTTP методы GET и POST используются для отправки данных на сервер.
Чаще всего методы используются в HTML формах, гиперссылках и AJAX запросах.
POST и GET запросы можно отправить на сервер с помощью любого программного обеспечения, работающего с протоколом HTTP.
Обработка запросов может отличаться в зависимости от типа сервера.
Какой метод использовать GET или POST, чем отличаются методы
Основное отличие метода GET от POST в способе передачи данных.
Запрос GET передает данные в URL в виде пар «имя-значение» (другими словами, через ссылку), а запрос POST передает данные в теле запроса (подробно показано в примерах ниже). Это различие определяет свойства методов и ситуации, подходящие для использования того или иного HTTP метода.
Например, можно использовать метод GET в HTML форме фильтра товаров: когда нужно, исходя из данных введенных пользователем, переправить его на страницу с отфильтрованными товарами, соответствующими его выбору.
HTTP метод POST поддерживает тип кодирования данных multipart/form-data, что позволяет передавать файлы.
Также следует заметить, что методы можно комбинировать. То есть, при необходимости вы можете отправить POST запрос на URL, имеющий GET параметры.
В каких случаях использовать POST и когда нужно использовать GET
В таблице ниже показаны распространенные варианты использования HTTP запросов с объяснением в чем разница между GET и POST запросами в конкретной ситуации.
| Ситуация | GET | POST |
|---|---|---|
| Фильтр товаров | ||
| AJAX запросы | Используются оба метода. Выбор зависит от контекста. Принципы выбора метода такие же, как и для HTML форм. | |
Сравнительная таблица HTTP методов GET и POST
В таблице ниже приведены основные свойства и отличия GET и POST методов.
| Свойство | GET | POST |
|---|---|---|
| Способ передачи данных | Через URL | В теле HTTP запроса |
| Защита данных | ||
| Кэширование | Страница с параметрами может быть кэширована | Страница с параметрами не может быть кэширована |
| Индексирование поисковыми системами | Страница с параметрами может быть индексирована | Страница с параметрами не может быть индексирована |
| Возможность отправки файлов | Не поддерживается | Поддерживается |
| Поддерживаемые типы кодирования | application/x-www-form-urlencoded | |
| Использование в гиперссылках | Да | Нет |
| Использование в HTML формах | Да | Да |
| Использование в AJAX запросах | Да | Да |
Пример использования GET запроса
В примере показана простая HTML форма фильтра по нескольким параметрам.
HTML код формы, генерирующей GET запрос:
После отправки формы браузер переведет пользователя по ссылке:
Ссылка содержит URL документа, отвечающего за обработку и блок параметров. Знак «?» отмечает начало блока параметров GET запроса. Далее находятся пары «имя-значение», разделенные знаком «&». Имена параметров отделены от значений знаком «=».
Переход по ссылке, приведенной выше, будет равнозначен отправке формы с указанными параметрами.
Пример использования POST запроса
В примере показана простая HTML форма авторизации.
HTML код формы, генерирующей POST запрос:
После отправки формы браузер переведет пользователя по ссылке:
Для того, чтобы увидеть переданные параметры, воспользуемся инструментами разработчика.
Запрос состоит из области заголовков и тела запроса.
В заголовках указана служебная информация: URL обработчика, тип кодирования, параметры браузера и т.д.
В теле запроса содержатся передаваемые параметры. Формат тела запроса может отличаться в зависимости от выбранного типа кодирования.
GET-запросы
Формат запроса
mode — метод группировки. Возможные значения:
Если параметр не задан, используется группировка по доменам.
Если параметр не задан, возвращается первая страница поисковой выдачи.
Имя пользователя. Должно совпадать с логином в Яндекс.Паспорте, заданным при регистрации.
Значение API-ключа, выданного при регистрации.
Текст поискового запроса. При обработке учитываются особенности языка запросов Яндекса (вместо специальных символов необходимо использовать соответствующие экранированные последовательности).
На запрос наложены следующие ограничения: максимальная длина запроса — 400 символов; максимальное количество слов — 40.
Идентификатор страны или региона поиска. Определяет правила ранжирования документов. Например, если передать в данном параметре значение «11316» (Новосибирская область), при формировании результатов поиска используется формула, определенная для Новосибирской области.
Список идентификаторов часто используемых стран и регионов приведен в приложении.
Возможные значения зависят от используемого типа поиска:
Правило сортировки результатов поиска. Возможные значения:
Если параметр не задан, результаты сортируются по релевантности.
При сортировке по времени изменения параметр может содержать атрибут order — порядок сортировки документов. Возможные значения:
Правило фильтрации результатов поиска (исключение из результатов поиска документов в соответствии с одним из правил). Возможные значения:
Если параметр не задан, используется умеренная фильтрация.
Максимальное количество пассажей, которое может быть использовано при формировании сниппета к документу. Пассаж — это фрагмент найденного документа, содержащий слова запроса. Пассажи используются для формирования сниппетов — текстовых аннотаций к найденному документу.
Допустимые значения — от 1 до 5. Результат поиска может содержать меньшее количество пассажей, чем значение, указанное в данном параметре.
Если параметр не задан, для каждого документа возвращается не более четырех пассажей с текстом запроса.
mode — метод группировки. Возможные значения:
Если параметр не задан, используется группировка по доменам.
Номер запрашиваемой страницы поисковой выдачи. Определяет диапазон позиций документов, возвращаемых по запросу. Нумерация начинается с нуля (первой странице соответствует значение «0» ).
Если параметр не задан, возвращается первая страница поисковой выдачи.
Инициирует проверку пользователя для возможной защиты от роботов.
Имя пользователя. Должно совпадать с логином в Яндекс.Паспорте, заданным при регистрации.
Значение API-ключа, выданного при регистрации.
Текст поискового запроса. При обработке учитываются особенности языка запросов Яндекса (вместо специальных символов необходимо использовать соответствующие экранированные последовательности).
На запрос наложены следующие ограничения: максимальная длина запроса — 400 символов; максимальное количество слов — 40.
Идентификатор страны или региона поиска. Определяет правила ранжирования документов. Например, если передать в данном параметре значение «11316» (Новосибирская область), при формировании результатов поиска используется формула, определенная для Новосибирской области.
Список идентификаторов часто используемых стран и регионов приведен в приложении.
Возможные значения зависят от используемого типа поиска:
Правило сортировки результатов поиска. Возможные значения:
Если параметр не задан, результаты сортируются по релевантности.
При сортировке по времени изменения параметр может содержать атрибут order — порядок сортировки документов. Возможные значения:
Правило фильтрации результатов поиска (исключение из результатов поиска документов в соответствии с одним из правил). Возможные значения:
Если параметр не задан, используется умеренная фильтрация.
Максимальное количество пассажей, которое может быть использовано при формировании сниппета к документу. Пассаж — это фрагмент найденного документа, содержащий слова запроса. Пассажи используются для формирования сниппетов — текстовых аннотаций к найденному документу.
Допустимые значения — от 1 до 5. Результат поиска может содержать меньшее количество пассажей, чем значение, указанное в данном параметре.
Если параметр не задан, для каждого документа возвращается не более четырех пассажей с текстом запроса.
mode — метод группировки. Возможные значения:
Если параметр не задан, используется группировка по доменам.
Номер запрашиваемой страницы поисковой выдачи. Определяет диапазон позиций документов, возвращаемых по запросу. Нумерация начинается с нуля (первой странице соответствует значение «0» ).
Если параметр не задан, возвращается первая страница поисковой выдачи.
Инициирует проверку пользователя для возможной защиты от роботов.
Типы HTTP-запросов и философия REST
Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.
Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂
Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:
где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).
Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.
Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.
Пример HTTP-взаимодействия
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует
Ресурсы и методы
Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).
Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».
В игру вступает REST
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).
REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).
В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.
Проблемы?
Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.
PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.
Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.
С лета 2021 года Яндекс.Вебмастер стал информировать вебмастеров о наличии на сайтах страниц-дублей с GET-параметрами, причем помечается эта проблема как критичная, что многих пользователей приводит в ужас. Здесь мы расскажем что это за проблема и как от нее избавиться проще всего.
Что же такое GET-параметр — это динамический параметр в URL, с помощью которого возможно изменение содержимого документа. Самым частым примером URL с GET-параметром в интернет магазинах являются страницы пагинации, например, site/category?page=2 или сортировки, например, site/category?sotr=abc. page и sort являются параметрами. Таких параметров может быть бесконечное множество. Они могут генерироваться как изнутри самим сайтом (CMS), так и снаружи, например, добавляя UTM-метки для рекламных компаний вы создаете дубли страниц для поисковых систем.
Для этого Яндекс даже выпустил собственный подробный гайд.
Но он не раскрывает все методы, не рассказывает об их сильных и слабых сторонах и не описывает как эффективно комбинировать разные способы. Сначала мы опишем основные методы по отдельности, с их достоинствами и недостатками, а в конце самый эффективный способ комбинирования их.
В файл robots.txt добавить директиву Clean-param с перечислением всех возможных GET-параметров через амперсанд, например, для страниц site/category?page=2 и site/category?sotr=abc Clean-param: page&sort
Кроме исключения дублей из поисковой базы, директива позволяет эффективно передавать параметры со страницы с GET-параметром на страницу без него.
1. Так как GET-параметров может быть бесконечное количество, вам придется отслеживать появление новых параметров в поисковой выдаче и периодически обновлять директиву, поэтому способ подходит для небольших сайтов, либо для сайтов, которые генерируют мало GET-параметров.
2. Данная директива работает только для поисковой системы Яндекс.
3. Ограничение в 500 символов, при всем желании, не даст перечислить абсолютно все параметры в одной директиве.
Проставлять на страницах с GET-параметром атрибут с указанием URL канонической страницы, например, для site/category?page=2 тег будет выглядеть так
Такой способ тоже позволяет передавать параметры страницы, но менее эффективно.
Является не строгим правилом для поисковых систем, поэтому значительная часть страниц может без проблем попадать в поисковую базу.
Как использовать:
В файле robots.txt прописать директиву Disallow: *?*, чтобы закрыть от индексации абсолютно все страницы с GET-параметрам. Более жесткое правило для поисковых роботов, поэтому достаточно эффективно убирает дубли страниц из поисковой выдачи.
Недостатки:
1. Не позволяет передавать параметры на нужную страницу.
2. Полностью исключает посещение поисковым роботом закрытых страниц.
Не передает параметры страницы.
Сделав это раз вам больше не будет нужно мониторить появление новых дублей с GET-параметрами. Лучше всего комбинировать два метода Метатег robots и rel=canonical. Каждый из них будет дополнять друг-друга и компенсировать недостатки, а именно, canonical будет передавать все параметры со страницы с GET на основную, при этом, noindex будет более строгим правилом, что позволит сократить количество дублей страниц до минимума. Кроме того, оба этих способа работают для всех поисковых систем, а не только для Яндекс.
Чтобы внедрить данный метод к себе на сайт можно либо поставить ТЗ на разработку и разместить теги на всех страницах с GET-параметром (или только на нужных, либо поискать для своих систем управления готовые решения, например, на CMS Webasyst/Shop-Script есть несколько плагин, которые позволяют автоматизировать процесс простановки тегов по определенным условиям.
Ошибка Я. Вебмастера: найдены страницы дубли с GET-параметрами — что делать
Дубли страниц могут приводить к потери позиций в поисковой выдаче и снижать скорость индексации. Стоит понимать, что у поискового робота есть определенный лимит запросов к домену в день. Поэтому существует вероятность того, что он потратит все лимиты на сканирование мусорных страниц и не доберется до страниц с уникальным контентом.
О наличии проблемы с дублированным контентом свидетельствует сообщение в панели Вебмастера: «Найдены страницы дубли с GET параметрами». В своем сообщении Яндекс информирует вебмастера о том, что на некоторых страницах сайта размещен одинаковый контент, различающийся только гет-параметрами.
Что такое get-параметры на сайте
Если в поиске есть дублированные страницы из-за гет-параметров, Яндекс предлагает воспользоваться правилом Clean-param в robots.txt (правило действительно только для Яндекс, Google его не воспринимает).
В результате использования Clean-param поисковый робот Яндекса объединяет сигналы с дублированных страниц на основной. После того, как краулер узнает обо всех произошедших изменениях, страницы с не имеющими значение гет-параметрами исчезнут из поисковой выдачи.
Как использовать Clean-param
Для понимания того, как используется Clean-param, стоит привести простой пример. Существуют дубли страницы со следующими гет-параметрами:
Чтобы в результатах поиска учитывалась только основная страница http://mysite.ru/cat/auto/nissan/, нужно задать правило Clean-param в файле robots.txt:
User-agent: Yandex
Clean-param: sort&order /cat/auto/nissan/
Как использовать Disallow
Избавиться от страниц-дублей с GET-параметрами можно, используя директиву Disallow. Для примера возьмем те же страницы-дубли:
Чтобы в результатах поиска учитывалась только основная страница http://mysite.ru/cat/auto/nissan/, нужно задать правило в файле robots.txt:
User-agent: *
Disallow: *?sort=
Disallow: *&order=
Также можно закрыть от индексации ВСЕ Get-параметры одним правилом?
User-agent: *
Disallow: *?
Будьте осторожны! Используйте директиву Disallow очень внимательно, чтобы случайно не закрыть от индексации нужные страницы (например, не используйте правило, если карточки товара или категории в обязательном порядке содержат get-параметр в url).