Поддержка метода put

Вопрос по протоколу HTTP. Методы PUT и POST

Опять буду мучить сообщество глупыми вопросами…

Ситуация следующая: МК общается с компом через web-страничку. Нужно передать файлик с компа на МК. Есть такие методы в HTTP: PUT и POST. Почитал про них в инете — в общих чертах описано что их можно использовать для передачи файлов. Но вот конкретики никакой. Отсюда вытекает вопрос знатокам:
1. Какой метод лучше использовать PUT, POST, или может есть еще более правильный вариант?
2. Как правильно данный метод реализовать (код не нужно, достаточно словесного описания)?
3. Возможно ли простыми методами выбирать файл в дириктории компа (выпадающие меню и прочие виды) или забить на это и указать фиксированный путь (вводить путь вручную в форме)? Ну и если можно — то как это сделать?

  • вопросы,
  • HTTP,
  • PUT,
  • POST,
  • методы
  • 05 апреля 2012, 14:12
  • Ultrin

Комментарии ( 37 )

  • atd
  • 05 апреля 2012, 14:25
  • atd
  • 05 апреля 2012, 14:26
  • Ultrin
  • 05 апреля 2012, 14:40

если вдумчиво прочитать, то там будет всё что надо, и как форму сделать, и что там в МК придёт.

а вообще, коммент ниже кратко описал всё, что вам может потребоваться.

  • atd
  • 05 апреля 2012, 14:43

Что такое PUT я уже забыл. Так что про POST.
С различными новыми методами формирования пост-запроса тоже не знаком, только с отсылкой формы через POST.
Пункт 3 в этом случае без вариантов — только элемент для указания файла (type=«file»).
В случае запроса POST данные отсылаются в теле запроса, т.е:

Данные как правило кодируются как multipart/form-data, в этом случае в заголовках обязательно будет пункт

Бессмысленный набор символов после «boundary=» — разделитель, его необходимо из заголовка извлечь. Затем по этим разделителям поток данных разбивается на части (каждый разделитель — в отдельной строке, т.е. перед ним и после него обязательно CRLF, относящиеся к нему же, из исключений только разделители в первой и последней строках). Каждая часть имеет формат, похожий на запрос — несколько заголовков, пустая строка и собственно данные.
Выглядит это примерно так:

  • Vga
  • 05 апреля 2012, 14:33
  • JustACat
  • 05 апреля 2012, 14:38

… те самые атрибуты name у тегов » input type=«file» «.

  • JustACat
  • 05 апреля 2012, 14:40

Причем name=«fileup» и name=«some» это, емнип, как раз те самые атрибуты name у тегов

Ну и стоит еще отметить, что там файл вроде кодируется, или нет? Чем-то вроде base64?

  • Vga
  • 05 апреля 2012, 14:43
  • JustACat
  • 05 апреля 2012, 14:45

Может и base64 и вообще чёрти-знает-что. всё зависит от enctype формы, и если это m/f-d, то от content-type каждого парта.

но обычно для файлов используется multipart, и внутри octet-stream

  • atd
  • 05 апреля 2012, 14:47
  • atd
  • 05 апреля 2012, 14:50
  • Vga
  • 05 апреля 2012, 14:55
  • Ultrin
  • 05 апреля 2012, 14:59

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

даже если у вас полметра флэша и 64к рамы, то думаю не стоит их все тратить на поддержку редкоиспользуемых функций

  • atd
  • 05 апреля 2012, 16:00
  • Ultrin
  • 05 апреля 2012, 20:23

Как оно должно прийти на МК, понятия не имею, но вот на стороне ПК простейшая страничка:

Если вы такую страничку с вашего МК выдадите в браузер, то в нем будет форма для загрузки файла, с выбором файла и кнопкой Отправить.
После нажатия на кнопку обычно происходит загрузка файла на сервер, при этом файл обычно попадает на сервере в специальную папку для хранения временных файлов, а скрипт (php или другого рода страничка), который указан в атрибуте «action» как раз и получает массив с данными об этом файле, который обычно содержит имя файла, путь к нему в этой самой временной папке, код ошибки загрузки (если была ошибка), размер и т.п. Но так происходит в обычном мире, на обычном веб-сервере. У вас же в качестве сервера МК :)
Я бы на вашем месте сделал так: выдал бы с МК вот эту страничку, что я вам предложил, и попробовал бы с ПК отправить через нее на МК файл, а дальше разобрал бы то, что пришло на МК, уверен, там все было бы понятно.

Поддержка метода put

Поддержка метода PUT была изменена при переходе от PHP 3 к PHP 4. В PHP 4 вы должны использовать стандартный поток ввода для чтения файла, передаваемого методом HTTP PUT.

Example#1 Сохранение загруженного при помощи HTTP PUT файла в PHP 4

/* Данные PUT находятся в потоке stdin */
$putdata = fopen ( «php://stdin» , «r» );

/* Открываем файл для записи */
$fp = fopen ( «myputfile.ext» , «w» );

/* Читаем данные блоками размером в 1 KB и
записываем их в файл */
while ( $data = fread ( $putdata , 1024 ))
fwrite ( $fp , $data );

/* Закрываем потоки */
fclose ( $fp );
fclose ( $putdata );
?>

Note: Вся документация, приведенная ниже, касается исключительно PHP 3.

PHP поддерживает загрузку файлов методом HTTP PUT, который используется в клиентах Netscape Composer и W3C Amaya . Запрос PUT выглядит проще, чем в случае обыкновенной загрузки файла на сервер:

Такой вызов означает, что удаленный клиент хотел бы сохранить файл под именем /path/filename.html в дереве каталогов вашего веб-сервера. Очевидно, что возможность клиента автоматически перезаписывать файлы вашего веб-сервера при помощи Apache или PHP не является хорошим решением. Поэтому для того, чтобы обрабатывать такие запросы, вам необходимо указать веб-серверу PHP-скрипт, которому вы доверяете их обработку. В веб-сервере Apache вы можете сделать это, используя директиву Script. Она может находиться практически в любом месте конфигурационного файла Apache. Как правило, эта директива расположена внутри блока или же внутри блока . Сама запись выглядит следующим образом:

Это указывает веб-серверу Apache на необходимость перенаправлять по указанному адресу все PUT-запросы, контекст которых совпадает с контекстом, в которым вы разместили эту строку. Предполагается, что файлы с расширением .php обрабатываются, как PHP-скрипты, и что сам PHP установлен и работает.

Внутри вашего файла put.php file вы можете поместить что-нибудь похожее на это:

Приведенный код скопирует файл в место, запрошенное клиентом. Возможно, вы захотите выполнить какую-либо проверку и/или аутентифицировать пользователя, прежде чем выполнять копирование. Трюк состоит в том, что когда PHP видит PUT-запрос, он сохраняет полученный файл во временной папке, как и при загрузке методом POST. По окончании обработки запроса временный файл удаляется. Поэтому ваш PHP-скрипт, обрабатывающий PUT-запрос, должен скопировать куда-либо полученный файл. Имя временного файла хранится в переменной $PHP_PUT_FILENAME , а предполагаемое имя файла можно найти в переменной $REQUEST_URI (может быть другим на веб-серверах, отличных от Apache). Запрашиваемое имя файла указывается удаленным клиентом. Вы не обязаны следовать его указаниям. Например, вы можете скопировать все загруженные файлы в отдельный каталог.

HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

Тема 7: Определение методов HTTP (HTTP Method Definitions). Методы HTTP запросов

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В этой записи мы изучим с тобой HTTP методы. Для начала мы с тобой разберемся с видами HTTP методов, потом разберем безопасные HTTP методы, выделим идемпотентные методы. После чего я перечислю все HTTP методы с их кратким описание, а далее мы разберем каждый метод в отдельности. Надеюсь, примеры, используемые в данной публикации помогут тебе понять как работают все эти методы: GET, POST, HEAD, CONNECT, PUT, DELETE, OPTIONS и TRACE. Как всегда, если что-то непонятно или есть какие-то дополнения или заметил неточность — не стесняйся написать комментарий.

Определение методов HTTP (HTTP Method Definitions). Описание методов HTTP запросов

Виды HTTP методов запроса

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Стандарт HTTP 1.1 насчитывает восемь методов, но набор методов может быть расширен, хотя и не будет поддерживаться другими HTTP приложениями, которые полностью соответствую букве стандарта. Каждый HTTP запрос должен содержать метод. HTTP методы запроса делятся на идемпотентные и безопасные методы. Дам короткую справку: идемпотентные методы в HTTP должны при большом количестве идентичных HTTP запросах иметь такой же эффект, как и при одном единственном запросе, но в то же время ответ HTTP сервера не обязательно должен быть тем же самым. Вот такое вот противоречие.

Безопасные HTTP методы и идемпотентные HTTP методы запросов

Давайте посмотрим на разницу между HTTP методами. Сперва рассмотрим безопасные методы. HTTP стандарт четко говорит о том, что программа, которая работает с сетью интернет, представляет пользователя, поэтому она должна информировать пользователя о любых действиях, которые происходят и которые он может произвести, но которые могут иметь непредсказуемые значения для самого пользователя или для других лиц. Другими словами: ваш браузер должен информировать вас о любых действия во время HTTP соединения. Это не всегда так, но, по крайней мере, так сказано в стандарте протокола HTTP 1.1.

Безопасные HTTP методы (Safe method HTTP)

На данный момент принято соглашение о том, что HTTP методы GET и HEAD никогда не должны иметь иного значения, кроме загрузки, поэтому данные HTTP методы нужно рассматривать, как безопасные, это требование HTTP. Поэтому ваш браузер, когда используются методы POST, PUT или DELETE предупреждает вас о том, что может произойти потенциально опасное действие и спрашивает: нужно ли его выполнить.

Илон Маск рекомендует:  Что такое код mailparse_msg_get_part_data

Идемпотентные HTTP методы (Idempotent Methods HTTP)

Я уже вкратце объяснил суть идемпотентных HTTP методов: при использование таких методов побочные эффекты одинаковы как в случае однократного запроса, так и в случае многократного повторения одного и того же запроса, т.е. нагрузка одинакова, но HTTP ответ от сервера может поступать каждый раз разный. К идемпотентным методам относятся следующие HTTP методы: GET, HEAD, PUT и DELETE. Так же эффектом идемпотентности обладают HTTP методы OPTIONS и TRACE.

Краткий обзор HTTP методов

Давайте перечислим все методы HTTP протокола и дадим им краткое описание. Для удобства сведем HTTP методы в таблицу

Номер HTTP метод и его описание
1 HTTP метод GET

Метода GET в HTTP используется для получения информации от сервера по заданному URI (URI в HTTP). Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.

2 HTTP метод HEAD

HTTP метод HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.

3 HTTP метод POST

HTTP метод POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.

4 HTTP метод PUT

HTTP метод PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI.

5 HTTP метод DELETE

HTTP метод DELETE удаляет указанный в URI ресурс.

6 HTTP метод CONNECT

HTTP метод CONNECT преобразует существующее соединение в тоннель.

7 HTTP метод OPTIONS

HTTP метод OPTIONS используется для получения параметров текущего HTTP соединения.

8 HTTP метод TRACE

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

Мы вкратце рассмотрели все HTTP методы и дали им короткую характеристику. Давайте теперь более подробно остановимся на каждом из HTTP методов и приведем несколько примеров использования HTTP методов.

Описание HTTP метода GET. Пример использования HTTP метода GET

HTTP метод GET позволяет получать информацию с HTTP сервера. Информация, получаемая от сервера может быть любой, главное, чтобы она была в форме HTTP объекта, доступ к информации при использовании метода GET осуществляется через URI. Часто бывает так, что HTTP метод GET обращается к какому-то коду, а не к конкретной страницы (все CMS генерируют контент налету), поэтому метод GET работает так, что мы получаем не исходный код, который генерирует текст, а сам текст.

HTTP метод GET бывает двух видов: условный метод GET и частичный метод GET. Давайте сперва посмотрим на условный метод GET. Когда используется условный HTTP метод GET, то к HTTP сообщению добавляются следующие поля заголовков: If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Значение таких полей является какое-либо условие и если это условие выполняется, то происходит передача объекта, который хранится по указанному URI, если же условие не выполняется, то и сервер не передает никаких данных. Условный HTTP метод GET предназначен для уменьшения нагрузки на сеть.

Давайте теперь посмотрим на особенности работы частичного HTTP метода GET. Особенность частичного метода GET заключается в том, что в его заголовке присутствует поле Range. Когда используется частичные метод GET полезная информация, предназначенная для человека передается кусками, после чего она из этих кусков собирается. Не напоминает ли это вам скачивание файлов по HTTP протоколу, когда мы можем остановить загрузку, отключить браузер, потом опять включить браузер и закачка будет происходить ровно с того места, где она была приостановлена. Не стоит забывать, что поля заголовков — это параметры HTTP протокола, которые определяют, как будут работать клиент и сервер.

Сервер может кэшировать ответы на запросы с HTTP методом GET, но при соблюдение определенных требований, о которых мы поговорим чуть позже. Давайте лучше самостоятельно напишем HTTP запрос с методом GET и посмотрим, какой ответ мы можем получить от сервера:

16 Http. Методы get, head, post, put delete, trace.

HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов в формате HTML). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (В частности для этого используется HTTP-заголовок.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

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

Простота. Протокол прост в реализации, что позволяет легко создавать клиентские приложения.

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

Распространённость. При выборе протокола HTTP для решения конкретных задач немаловажным фактором является его распространённость. Как следствие, это обилие различной документации по протоколу на многих языках мира, включение удобных в использовании средств разработки в популярные IDE, поддержка протокола в качестве клиента многими программами и обширный выбор среди хостинговых компаний с серверами HTTP.

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

Стартовая строка (англ. Starting line) — определяет тип сообщения;

Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;

Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

GET URI — для версии протокола 0.9.

Метод URI HTTP/Версия — для остальных версий.

Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.

URI определяет путь к запрашиваемому документу.

Версия (англ. Version) — пара разделённых точкой цифр. Например: 1.0

Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение, где:

Версия — пара разделённых точкой цифр как в запросе.

Код состояния (англ. Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента.

Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:

Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Кроме методов GET и HEAD, часто применяется метод POST.

OPTIONS Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.

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

Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Результат выполнения этого метода не кэшируется.

Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:

GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.

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

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

При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

Аналогично PUT, но применяется только к фрагменту ресурса.

Удаляет указанный ресурс.

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

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

Убирает связь указанного ресурса с другими.

Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через нешифрованный прокси.

Методы HTTP

Практически все, кто связан с веб-разработкой, знают два метода HTTP — это GET и POST. Но кроме этих методов — есть и другие, не менее полезные методы, которые могут пригодится в повседневной работе и облегчить многие ежедневные процессы.Абсолютно любой веб-сервер должен работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501, если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405. Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

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

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.

Метод GET

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

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1&param2=val2 HTTP/1.1.

Как установлено в стандарте HTTP, запросы методом GET, являются идемпотентными, то есть, повторная отправка одного и того-же запроса, методом GET, должна приводить к одному и тому-же результату, в случае, если сам ресурс, в промежутках между запросами, изменен не был, что позволяет кэшировать результаты, выдаваемые на запрос методом GET.

Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.

Метод HEAD

Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.

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

Метод POST

Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.

В отличии от GET, метод POST, не является идемпотентным, то есть неоднократное повторение запроса POST, может выдавать разные результаты. В нашем случае, будет появляться новая копия комментария при каждом запросе.

Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.

Ответы сервера, на выполнение метода POST, не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).

Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

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

Связывает указанный ресурс с другим ресурсом.

PUT & POST при написании API

POST: Replace the addressed member of the collection, or if it doesn’t exist, create it.

POST запрос подразумевает создание записи, результатом ее должены быть пустое тело ответа и заголовок location c uri нового объекта.

PUT — подмена записей. Тобиш обновить одно какое-то поле у записи нельзя. Опять же, если вы заменили объект — то вы уже имеете на руках все нужные данные, посему ответом может быть опять же заголовок location.

есть еще метод PATCH, который позволяет именно обновлять запись (конкретное поле или несколько из них). Тут тоже подразумевается возврат только URI. По сути какие либо данные вам может вернуть только GET запрос.

И есть еще куча заморочек со статус кодами, мол 200 это хорошо только для GET, так как оно имеет тело ответа. А для большинства других нужен 204, который говорит что все хорошо, но есть только заголовки.

НО… это если по феншую и именно RESTFull, причем это далеко не все. Обычно дальше GET/POST/PUT/DELETE никто не идет… PATCH вообще редко используют, а вот LINK вообще ниразу не видел что бы на реальных проектах применяли…

Кратко: POST — создание, PUT — обновление
Авторитетного источника применительно к REST не будет, так как REST, строго говоря, не определяет ни POST, ни PUT. REST просто допускает использование HTTP. Следовательно наиболее авторитетный источник по поводу POST/PUT — это спецификация HTTP 1.1:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

То есть POST используется для создания подчиненной сущности, а PUT для сохранения сущности.
POST в случае успеха всегда должен возвращать статус 201 (Created) и Location на новый ресурс.
PUT же может возвращать как 201 (если ресурс не найден), так и 204 (No Content) — если ресурс обновлялся.

PUT должен быть идемпотентной операцией, т.е. несколько одинаковых последовательных пут-запросов на один урл (и с одинаковыми параметрами) не должны создавать новых объектов.

POST, в свою очередь, может создавать новые объекты при последовательных запросах на один урл.
Другими словами, POST нужно использовать для обращения к «производящим фабрикам».

Первая подручная статья, в которой это объясняется: на английском.

И да, PUT можно сравнить с INSERT… OM DUPLICATE KEY UPDATE.
POST — это чистый INSERT.

1. Как мне кажется наиболее эффективный метод работы выглядит следующим образом
GET /reports(.:format) reports#index (коллекция)
GET /reports/:report_id/images image#index (коллекция)
POST /reports(.:format) reports#create (создание)
GET /reports/new(.:format) reports#new (инициализация, удобный прием, в разрезе REST можно не рассматривать)
GET /reports/:id/edit(.:format) reports#edit (иницаилизация, данные для редактирования)
GET /reports/:id(.:format) reports#show (конкретный объект)
PUT /reports/:id(.:format) reports#update
DELETE /reports/:id(.:format) reports#destroy
DELETE /reports/:report_id/images images#destroy
PUT для коллекций ниразу не пришлось использовать, выдумывать ничего не буду

2. Вторая часть рест — коды ошибок
Например эффективно используется в связке с jQuery: евенты success, error и т.д. отзываются корректно.

3. (самое важное) Межсистемное взаимодействие.
Restfull API интуитивно понятен разработчикам сторонней системы, если конечно разработчики представляют что такое рест
В любом случае, при межсистемном взаимодействии, важно пользоваться единым стандартом, а разрабатывать его налету — опасно. Большинство выбрали REST, если я не заблуждаюсь.

4. Никакой путаницы.
Ни в приложении, ни во фронтенде, ни в API, при использовании REST, вы совершаете одинаковые действия, с одинаковыми объектами, обращаясь на одинаковые URL, с одинаковыми наборами параметров. Поведение всех систем предсказуемое, все подвластно единой концепции.

Поддержка метода put

Поддержка метода PUT была изменена при переходе от PHP 3 к PHP 4. В PHP 4 вы должны использовать стандартный поток ввода для чтения файла, передаваемого методом HTTP PUT.

Пример #1 Сохранение загруженного при помощи HTTP PUT файла в PHP 4

/* Данные PUT находятся в потоке stdin */
$putdata = fopen ( «php://stdin» , «r» );

/* Открываем файл для записи */
$fp = fopen ( «myputfile.ext» , «w» );

/* Читаем данные блоками размером в 1 KB и
записываем их в файл */
while ( $data = fread ( $putdata , 1024 ))
fwrite ( $fp , $data );

/* Закрываем потоки */
fclose ( $fp );
fclose ( $putdata );
?>

Замечание: Вся документация, приведенная ниже, касается исключительно PHP 3.

PHP поддерживает загрузку файлов методом HTTP PUT, который используется в клиентах Netscape Composer и W3C Amaya . Запрос PUT выглядит проще, чем в случае обыкновенной загрузки файла на сервер:

Такой вызов означает, что удаленный клиент хотел бы сохранить файл под именем /path/filename.html в дереве каталогов вашего веб-сервера. Очевидно, что возможность клиента автоматически перезаписывать файлы вашего веб-сервера при помощи Apache или PHP не является хорошим решением. Поэтому для того, чтобы обрабатывать такие запросы, вам необходимо указать веб-серверу PHP-скрипт, которому вы доверяете их обработку. В веб-сервере Apache вы можете сделать это, используя директиву Script. Она может находиться практически в любом месте конфигурационного файла Apache. Как правило, эта директива расположена внутри блока или же внутри блока . Сама запись выглядит следующим образом:

Это указывает веб-серверу Apache на необходимость перенаправлять по указанному адресу все PUT-запросы, контекст которых совпадает с контекстом, в которым вы разместили эту строку. Предполагается, что файлы с расширением .php обрабатываются, как PHP-скрипты, и что сам PHP установлен и работает.

Внутри вашего файла put.php file вы можете поместить что-нибудь похожее на это:

Приведенный код скопирует файл в место, запрошенное клиентом. Возможно, вы захотите выполнить какую-либо проверку и/или аутентифицировать пользователя, прежде чем выполнять копирование. Трюк состоит в том, что когда PHP видит PUT-запрос, он сохраняет полученный файл во временной папке, как и при загрузке методом POST. По окончании обработки запроса временный файл удаляется. Поэтому ваш PHP-скрипт, обрабатывающий PUT-запрос, должен скопировать куда-либо полученный файл. Имя временного файла хранится в переменной $PHP_PUT_FILENAME , а предполагаемое имя файла можно найти в переменной $REQUEST_URI (может быть другим на веб-серверах, отличных от Apache). Запрашиваемое имя файла указывается удаленным клиентом. Вы не обязаны следовать его указаниям. Например, вы можете скопировать все загруженные файлы в отдельный каталог.

Загрузка методом POST

PHP способен принимать загрузку файлов из любого RFC-1867-соответствующего браузера (в том числе — Netscape Navigator 3 и новее, Microsoft Internet Explorer 3 с патчем от Microsoft или новее без патча). Это даёт возможность загружать текстовые и бинарные файлы. С помощью функций РНР для аутентификации и манипуляций с файлами вы получаете полный контроль над тем, кому разрешено загружать файлы, и над тем, что делать с файлом после его загрузки.

Заметьте, что PHP поддерживает также загрузку методом PUT, который используется в Netscape Composer и в Amaya-клиентах W3C. См. также «Поддержка метода PUT «.

Экран загрузки файлов может быть создан с помощью специальной формы примерно так:

Пример 19-1. Форма для загрузки файлов

_URL_ должен указывать на PHP-файл. Скрытое поле MAX_FILE_SIZE обязано предшествовать полю ввода файла/file input field, и его значение это максимальный размер принимаемого файла. Значение в байтах.

MAX_FILE_SIZE является для браузера лишь уведомляющим. Легко обойти этот максимум. Поэтому не рассчитывайте, что браузер будет повиноваться вашим желаниям! Однако PHP-установки maximum-size обмануть нельзя.

Переменные, определяемые для загруженных файлов, зависят от версии PHP и конфигурации. Следующие переменные будут определены в скрипте назначения после успешного завершения загрузки. Если track_vars включена, инициализируется массив $HTTP_POST_FILES/$_FILES. Наконец, соответствующие переменные могут быть инициализированы как глобалы, если register_globals включена. Однако использовать глобалы больше не рекомендуется.

Примечание: track_vars всегда включена, начиная с версии PHP 4.0.3. Начиная с версии PHP 4.1.0, можно использовать $_FILES вместо $HTTP_POST_FILES .
$_FILES всегда является глобальной, поэтому global не должно использоваться для $_FILES в области видимости функции.

$HTTP_POST_FILES / $_FILES предоставлены для вмещения информации загруженных файлов.

Далее идёт содержимое $_FILES . Обратите внимание, что здесь предполагается использование имени ‘userfile’ для загружаемого файла, как в примере скрипта ранее: $_FILES[‘userfile’][‘name’]

Оригинальное имя файла на клиентской машине.

mime-тип файла, если браузер предоставил эту информацию. Пример: «image/gif» .

Размер загруженного файла в байтах.

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

Примечание: в PHP версии до 4.1.0 она называлась $HTTP_POST_VARS и не была автоглобальной переменной. PHP 3 не поддерживает $HTTP_POST_FILES .

Если register_globals включена в php.ini , то будут доступны нижеследующие переменные. Обратите внимание, что имена этих переменных предполагают использование имя файла для загрузки ‘userfile’, как в примере предыдущего скрипта:


$userfile — Временное имя файла, под которым загруженный файл был сохранён на сервере.

$userfile_name — Оригинальное имя или путь к файлу на системе отправителя.

$userfile_size — Размер загруженного файла в байтах.

$userfile_type — mime-тип файла, если браузер предоставил эту информацию. Пример: «image/gif» .

Заметьте, что часть » $userfile » этих переменных это имя, которое записано в поле type=»file» в форме загрузки. В предыдущем примере формы мы назвали её «userfile».

Примечание: register_globals = On не рекомендуется по соображениям производительности и обеспечения безопасности.

Файлы будут по умолчанию сохраняться во временной директории по умолчанию на сервере, если только не задано другое место директивой upload_tmp_dir в php.ini . Директория по умолчанию сервера может быть изменена через установку переменной окружения TMPDIR в среде, в которой работает PHP. Установка её с использованием putenv() из РНР-скрипта не будет работать. Эта переменная окружения может также использоваться для того, чтобы гарантировать, что другие операции также работают с загруженными файлами.

Предупреждение!

Пример 19-2. Проверка загрузки файлов

Следующие примеры предназначены для версий PHP 4 выше 4.0.2. См. о функциях is_uploaded_file() и move_uploaded_file() .

PHP-скрипт, который получает загружаемый файл, должен реализовывать логику, необходимую для определения того, что нужно сделать с загруженным файлом. Вы можете, например, использовать переменную $_FILES[‘userfile’][‘size’] для исключения файлов, которые слишком малы или велики. Вы можете использовать переменную $_FILES[‘userfile’][‘type’] для исключения файлов, которые не отвечают критериям определённого типа. При любой логике вы должны либо удалять, либо перемещать такие файлы из временной директории.

Файл будет удалён из временной директории по окончании запроса, если он (файл) не перемещён или не переименован.

Разница между PUT и POST

Разница между PUT и POST — это вопрос семантики. Коль скоро для операций используются разные глаголы, то и смысл у них должен быть разным.

Представьте, что ваш сервис оперирует понятиями блокнот (notebook) и запись (post). Один блокнот может содержать множество записей.

Для добавления новой записи в блокнот c идентификатором id вы будете использовать метод POST с URL mydomain/notebooks/id/. Ваш сервис, ориентируясь на метод POST, сам присвоит нужный идентификатор записи, добавит ее в блокнот и вернет вам URL созданной записи (для доступа к записи по GET или для удаления по DELETE). При этом хорошо бы вернуть клиенту URL созданной записи.

Допустим, запись с идентификатором post-id уже создана и доступна по URL mydomain/notebooks/id/posts/post-id. Но клиент (владелец записи) исправил в ней ошибку и хочет перезаписать ее. Для этого он использует метод PUT с URL mydomain/notebooks/id/posts/post-id и передает обновленную запись в теле запроса. Ваш сервис, ориентируясь на метод PUT удаляет старую запись и записывает новую, при этом она доступна по тому же URL.

Конечно, никто не мешает вам всегда использовать метод POST (например HTML 4 позволял использовать только методы GET и POST). Но все же стоит придерживаться рекомендаций в целях единообразной трактовки методов всеми разработчиками.

ПС: Проще говоря чтобы придерживаться архитектурного стиля RESTful API мы используем метод POST для добавления новой записи в ответ получаем уникальный ключ, с которым в последствии можем редактировать запись методом PUT, удалять методом DELETE и запрашивать методом GET.

Поддержка методаPUT

PHP поддерживает HTTP-метод PUT, используемый такими клиентами, как Netscape Composer и W3C Amaya. PUT-запросы намного проще, чем загрузка файлов и выглядят примерно так:

Нормально это должно означать, что удалённый клиент хотел бы сохранить содержимое /path/filename.htm в вашем web-дереве. Для Apache или PHP, очевидно, не очень-то здорово разрешить любому автоматически перезаписывать любые файлы в вашем web-дереве. Поэтому, чтобы обрабатывать такие запросы, вы должны сначала указать вашему web-серверу, что вы хотите, чтобы определённый PHP-скрипт обрабатывал запрос. В Apache вы делаете это директивой Script . Она может быть размещена почти в любом месте файла конфигурации вашего Apache. Обычно это в блоке или, возможно, в блоке . Строка типа этой выполняет трюк:

Это указывает серверу Apache, что нужно отправить все PUT-запросы по URI, которые совпадают с контекстом, в котором вы поместили эту строку в скрипт put.htm. Это предполагает, разумеется, что PHP включён для расширений .htm и что PHP активен.

В файле put.htm вы можете тогда записать что-нибудь такое:

Это скопирует файл в место, запрошенное удалённым клиентом. Вы, возможно, захотите выполнить какую-нибудь проверку и/или аутентифицировать пользователя, прежде чем выполнить копирование файла. Трюк состоит в том, что, когда PHP видит запрос методом PUT, он сохраняет загруженный файл во временной директории, как и при работе методом POST. Когда запрос завершается, этот временный файл удаляется. Поэтому ваш РНР-скрипт обработки PUT должен скопировать файл куда-нибудь. Имя этого временного файла находится в переменной $PHP_PUT_FILENAME, а предполагаемое имя файла назначения можно найти в $REQUEST_URI (может называться иначе на не-Apache web-серверах). Это имя файла, специфицированное удалённым клиентом. Вам не нужно прослушивать этот клиент. Вы можете, например, скопировать все загруженные файлы в специальную директорию.

Илон Маск рекомендует:  Функции net
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL