php get request body
http_get_request_body
(PECL pecl_http >= 0.10.0)
http_get_request_body — Получает тело запроса в виде строки
Описание
Получает исходное тело запроса (например POST или PUT данные).
Данная функция не может быть использована после http_get_request_body_stream() если запрос выполнен методом, отличным от POST.
Список параметров
Возвращаемые значения
Возвращает исходное тело запроса в виде строки в случае успеха или NULL в случае неудачи.
Смотрите также
User Contributed Notes 4 notes
For example, if you are trying to test out a custom SOAP server app and you send a request like this without a Content-Length set:
——
POST /soap_service.php HTTP/1.1
Authorization: Basic abcdefgh
User-Agent: SOAPy McSOAPclient
Host: example.com
Accept: */*
MIME-Version: 1.0
Content-type: text/xml; charset=utf-8
«php://input» will always return and empty string.
@slave at codegrunt dot com
If you leave out Content-Length and have no Transfer-Encoding, your request is no longer valid.
RFC261 says at chapter 4.3:
«The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request’s message-headers.»
Without those headers, the server has no way of figuring out what the length of the body is. For a response, you could indicate it with a connection close, but obviously if you do that on a request you will never get a response!
So, I assume the PhP behaviour you describe is OK as you cannot expect it to auto-magically repair all sorts of broken requests!
Как отправить body с помощью get запроса?
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
передача body в get запросе это нормальное действие в http протоколе
И показывает мне на примере работы программы Posman что все нормально работает и json передаётся.
Помогите популярно растолковать, что это не корректно хоть и глобально «не запрещено«
Более того, браузеры в принципе не отправят body в GET-запросе
https://stackoverflow.com/a/45550919/1016033
If either init[«body»] exists and is non-null or inputBody is non-null, and request’s method is `GET` or `HEAD`, then throw a TypeError.
If this’s request method is `GET` or `HEAD`, then set body to null.
Да, как уже написали, из браузера вы в принципе body через get не отправите.
Да и вообще это бредовенько как-то. Хоть формально и разрешено.
А если ваш бэкендер такой умный, то сам пускай и попробует. А вы ему свою зп, в случае успеха. А если не получится, а не получится, то он вам свою))
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
Т.е. gолезная нагрузка в сообщении запроса GET не имеет определенной семантики; отправка тела полезной нагрузки в запросе GET может привести к тому, что некоторые существующие реализации отклонят запрос. Если обратиться к более старым спецификациям, то там вообще написано, что надо игнорировать тело при GET. Да и вообще посмотрите на API крупных сервисов, хоть где-то при работе с ними вы в гете отправляете body?), а еще можете привести в пример Swagger и поведение GET там (Swagger ни за что в жизни не отправит body в GET). Но на любой пример есть и антипример, например, Elasticsearch принимает body в GET. Также если полезть в спецификацию, то согласно RFC 2119 разработчики могут слать body, если на то есть веские причины, наверное, к этим причинам можно отнести большое число параметров или если это body не изменит какие-то данные.
Типы 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.
Когда мы должны использовать Query, а когда Body в HTTP?
Всем привет. Подскажите, пожалуйста, есть ли какие-то ограничения в спецификации HTTP / REST, которые устанавливают ограничение на использование Query или Body?
Сама концепция REST настолько размыта, что стандартного ответа на ваш вопрос нету. То что вы используйте и видите это чаще всего не REST в том академическом плане в каком он был создал.
Вот хорошее мнение на этот счет. Но я ни где не находил его подтверждения.
https://habr.com/ru/company/yandex/blog/265569/
На самом деле все предельно просто.
URL является частным случаем URI, который в свою очередь расшифровывается как «Uniform Resource Identifier». То есть это в первую очередь идентификатор ресурса. По нему мы находим ресурс, обращаемся к ресурсу, отличаем его от других ресурсов.
Query же, это такая же часть URI, как и host или path, и так же принимает участие в идентификации ресурса.
В Body же как раз содержатся данные, отправляемые ресурсу на обработку. Потому в GET запросах и нет тела, так как запрашивая данные ты не отправляешь никаких данных на обработку, но тебе нужно четко идентифицировать тот ресурс, от которого ты хочешь эти данные получить. А идентифицируешь ты его при помощи url, в том числе query, если нужно.
PATCH /user или PUT /user/password значения не имеет, но обычно разработчикам день программировать новые эндпоинты, поэтому используют более общий PATCH /user.