пример post запроса http с параметрами

HTTP-запрос методом POST.

Кроме метода GET, который мы рассмотрели в предыдущей заметке, существует еще один метод отправки запроса по протоколу HTTP – метод POST. Метод POST тоже очень часто используется на практике.

Если, для того, чтобы обратиться к серверу методом GET, нам достаточно было набрать запрос в URL-адрес, то в методе POST все работает по другому принципу.

Для того, чтобы выполнить этот вид запроса, нам необходимо нажать на кнопку с атрибутом type=»submit», которая расположена на веб-странице. Обратите внимание, что эта кнопка расположена в элементе

Если пользователь введет в текстовое поле какой-либо текст и нажмет на кнопку «Отправить», то на сервер будет отправлена переменная text со значением того содержимого, которое ввел пользователь. Эта переменная будет отправлена методом POST.

Если в форме написать так:

То данные будут отправляться методом GET.

Если, в случае с GET-запросом, объем данных, которые мы могли передать ограничивался длиной адресной строки браузера, то в случае с запросом POST, такого ограничения нет, и мы можем передавать значительные объемы информации.

Еще одно отличие метода POST от GET, метод POST скрывает все передаваемые им переменные и их значения, в своём теле (Entity-Body). В случае с методом GET они хранились в строке запроса (Request-URI).

Вот пример запроса, выполненного методом POST:

Таким образом, передавая данные методом POST, их будет намного труднее перехватить злоумышленнику, т.к. они скрыты от непосредственного просмотра, поэтому метод передачи данных методом POST считается более безопасным способом.

Кроме того, методом POST можно передавать не только текст, но и мультимедиа данные (картинки, аудио, видео). Существует специальный параметр Content-Type, который определяет тот вид информации, который необходимо передать.

Ну и, наконец, чтобы на сервере получить данные, которые были переданы этим методом, используется переменная POST.

Вот пример обработки на языке PHP:

Все мои уроки по серверному программированию здесь.

Источник

POST-запросы

URL запроса

Имя пользователя. Должно совпадать с логином в Яндекс.Паспорте, заданным при регистрации.

Значение API-ключа, выданного при регистрации.

Правило фильтрации результатов поиска (исключение из результатов поиска документов в соответствии с одним из правил). Возможные значения:

Если параметр не задан, используется умеренная фильтрация.

Идентификатор страны или региона поиска. Определяет правила ранжирования документов. Например, если передать в данном параметре значение «11316» (Новосибирская область), при формировании результатов поиска используется формула, определенная для Новосибирской области.

Список идентификаторов часто используемых стран и регионов приведен в приложении.

Возможные значения зависят от используемого типа поиска:

Инициирует проверку пользователя для возможной защиты от роботов.

Имя пользователя. Должно совпадать с логином в Яндекс.Паспорте, заданным при регистрации.

Значение API-ключа, выданного при регистрации.

Правило фильтрации результатов поиска (исключение из результатов поиска документов в соответствии с одним из правил). Возможные значения:

Если параметр не задан, используется умеренная фильтрация.

Идентификатор страны или региона поиска. Определяет правила ранжирования документов. Например, если передать в данном параметре значение «11316» (Новосибирская область), при формировании результатов поиска используется формула, определенная для Новосибирской области.

Список идентификаторов часто используемых стран и регионов приведен в приложении.

Возможные значения зависят от используемого типа поиска:

Инициирует проверку пользователя для возможной защиты от роботов.

Формат тела запроса

Текст поискового запроса. При обработке учитываются особенности языка запросов Яндекса (вместо специальных символов необходимо использовать соответствующие экранированные последовательности).

На запрос наложены следующие ограничения: максимальная длина запроса — 400 символов; максимальное количество слов — 40.

Правило сортировки результатов поиска. Возможные значения:

Если параметр не задан, результаты сортируются по релевантности.

При сортировке по времени изменения параметр может содержать атрибут order — порядок сортировки документов. Возможные значения:

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

Допустимые значения — от 1 до 5. Результат поиска может содержать меньшее количество пассажей, чем значение, указанное в данном параметре.

Если параметр не задан, для каждого документа возвращается не более четырех пассажей с текстом запроса.

Номер запрашиваемой страницы поисковой выдачи. Определяет диапазон позиций документов, возвращаемых по запросу. Нумерация начинается с нуля (первой странице соответствует значение «0» ).

Если параметр не задан, возвращается первая страница поисковой выдачи.

mode — метод группировки. Возможные значения:

Если параметр не задан, используется группировка по доменам.

Текст поискового запроса. При обработке учитываются особенности языка запросов Яндекса (вместо специальных символов необходимо использовать соответствующие экранированные последовательности).

На запрос наложены следующие ограничения: максимальная длина запроса — 400 символов; максимальное количество слов — 40.

Правило сортировки результатов поиска. Возможные значения:

Если параметр не задан, результаты сортируются по релевантности.

При сортировке по времени изменения параметр может содержать атрибут order — порядок сортировки документов. Возможные значения:

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

Допустимые значения — от 1 до 5. Результат поиска может содержать меньшее количество пассажей, чем значение, указанное в данном параметре.

Если параметр не задан, для каждого документа возвращается не более четырех пассажей с текстом запроса.

Номер запрашиваемой страницы поисковой выдачи. Определяет диапазон позиций документов, возвращаемых по запросу. Нумерация начинается с нуля (первой странице соответствует значение «0» ).

Если параметр не задан, возвращается первая страница поисковой выдачи.

mode — метод группировки. Возможные значения:

Если параметр не задан, используется группировка по доменам.

При необходимости используйте Валидатор XML-фидов сервиса Яндекс.Вебмастер. Подробные сведения о валидации приведены в приложении.

Источник

Методы 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 запросами в конкретной ситуации.

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

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

Отсутствует защита конфиденциальной информации. Введенный пароль будет виден в адресной строке браузера, будет сохранен в истории посещенных сайтов.

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

При повторном обращении по конечной ссылке на сервере будет произведена повторная обработка, например, будет создана повторная заявка, оформлен еще один заказ, создан еще один запрос на обратную связь.

Повторное обращение по конечной ссылке не приведет к повторной обработке запроса с введенными ранее параметрами.

Переход по гиперссылке с параметрами равнозначен отправке запроса через HTML форму.

Нет технической возможности поместить POST запрос в гиперссылку.

Сравнительная таблица HTTP методов GET и POST

В таблице ниже приведены основные свойства и отличия GET и POST методов.

Данные видны всем в адресной строке браузера, истории браузера и т.п.

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

Не более 2048 символов

Примечание: ограничения могут быть установлены сервером.

Страница с параметрами может быть добавлена в закладки

Страница с параметрами не может быть добавлена в закладки.

Пример использования GET запроса

В примере показана простая HTML форма фильтра по нескольким параметрам.

HTML код формы, генерирующей GET запрос:

После отправки формы браузер переведет пользователя по ссылке:

Ссылка содержит URL документа, отвечающего за обработку и блок параметров. Знак «?» отмечает начало блока параметров GET запроса. Далее находятся пары «имя-значение», разделенные знаком «&». Имена параметров отделены от значений знаком «=».

Переход по ссылке, приведенной выше, будет равнозначен отправке формы с указанными параметрами.

Пример использования POST запроса

В примере показана простая HTML форма авторизации.

HTML код формы, генерирующей POST запрос:

После отправки формы браузер переведет пользователя по ссылке:

Для того, чтобы увидеть переданные параметры, воспользуемся инструментами разработчика.

Запрос состоит из области заголовков и тела запроса.

В заголовках указана служебная информация: URL обработчика, тип кодирования, параметры браузера и т.д.

В теле запроса содержатся передаваемые параметры. Формат тела запроса может отличаться в зависимости от выбранного типа кодирования.

Источник

Типы 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.

Источник

Учимся создавать http сервис (часть четвертая). Изучение метода POST http запроса (передача текстовых данных)

-Перенесем данные справочника «Номенклатура» из базы источник в базу приемник при помощи http сервиса, используя POST запрос. Переносить данные будем в JSON формате.

Подготовим базу источник.

-Создаем чистую информационную базу.

-Назовем ее «БазаИсточник»

-Добавляем в нее несколько объектом метаданных:

Реквизит «Атрикул» тип строка 25

— Обработка «Изучение POST Запросов»

Подготовим базу приемник

-Создаем чистую информационную базу

-Назовем ее «БазаПриемник»

-Добавим в нее несколько объектов метаданных:

Реквизит «Атрикул» тип строка 25

-Создаем новый http сервис «Изучение POST Запросов»

-Корневой URL – « post »

-Переходим на закладку «Шаблоны URL »

— Добавляем новый шаблон «ЗагрузкаНоменклатуры»

-Создадим шаблон, назовем его « product _ json »

— Добавим новый метод «ЗагрузкаНоменклатурыJSON»

-Публикуем http сервис на веб сервере, если забыли, как это сделать, смотрите статью

После публикации у меня получился следующий путь «http://localhost/post_test/hs/post/product_json/»

Localhost – IP адрес

post_test – имя публикации

hs – признак http сервиса

post – корневой каталог

Переходим в базу источник.

-Открываем обработку «Изучение POST Запросов»

-Создадим форму. На форме разместим кнопку «Перенести номенклатуру JSON »

Шаблон, по которому мы подключаемся из 1С к http сервису следующий:

-Создаем объект типа «HTTPСоединение», в его конструкторе передаем ip адрес http сервиса, например, так:

— Создаем объект типа «HTTPЗапрос», в его конструкторе указываем адрес ресурса и заголовки, например так:

-Помещаем данные, которые мы хотим отправить на сервер в тело запроса. Мы хотим передать текстовые данные, для этого мы воспользуемся методом «УстановитьТелоИзСтроки»

-Отправляем данные на сервер. (пример кода)

Еще раз. Для того чтобы передать данные на сервер, надо эти данные поместить в тело POST запроса. В заголовке необходимо указать какого типа эти данные.

-Открываем базу источник в режиме предприятия и добавляем в справочник «Номенклатура» несколько элементов.

Базу источник мы подготовили!

Переходим в базу приемник

— Добавляем общий модуль «ОбщегоНазначения»

-В нем описываем две процедуры

-Переходим в обработчик метода «ЗагрузкаНоменклатурыJSON» http сервиса «ИзучениеPOSTЗапросов»

-Описываем в нем следующий код

Базу приемник мы подготовили.

Запускаем обработку из базы источник. Нажимаем на кнопку. И в базе приемнике создается номенклатура.

Видео инструкция тут:

Там же, вы сможете скачать файлы конфигурации источника и приемника.

Итак, мы решили поставленную задачу.

При реализации данного функционала была использована платформа 1С:Предприятие 8.3 (8.3.12.1567)

Специальные предложения

обработка ИзучениеPOSTЗапросов
а на картинке Изчение POSTЗапросов

для JSON наверное правильнее
HTTPЗапрос.Заголовки.Вставить(«Content-Type»,»application/json»);

А передать данные в теле запроса можно и методами PATCH, PUT, а не только POST.

Так, распространённая практика при создании REST API использовать POST для создание объекта, а PUT/PATCH для его изменения (метод DELETE, соответственно, используется для удаления).

А вообще, все эти методы используются на усмотрение программиста. Встречался с таким, что для всех запросов использовался только POST (и для получения данных, и для передачи).

По поводу заголовка Content-Type. Вы указываете text/plain, а передаёте json (Content-Type: application/json). А если учесть, что база-приёмник ни как этот заголовок не использует, то его вообще можно не передавать.

Источник