Этот пост - ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

HTTP

Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.

Стартовые строки для запроса и ответа имеют различный формат - нам интересна только стартовая строка запроса, которая выглядит так:

METHOD URI HTTP/VERSION ,

Где METHOD - это как раз метод HTTP-запроса, URI - идентификатор ресурса, VERSION - версия протокола (на данный момент актуальна версия 1.1).

Заголовки - это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.

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

Пример HTTP-взаимодействия

Запрос:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
Первая строка - это строка запроса, остальные - заголовки; тело сообщения отсутствует

Ответ:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close ... САМА HTML-СТРАНИЦА...

Ресурсы и методы

Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно - получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».

Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты:

• GET - получение ресурса
• POST - создание ресурса
• PUT - обновление ресурса
• DELETE - удаление ресурса

В игру вступает REST

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 - удаляет.

Проблемы?

PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.

Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем "_method", а в качестве значения указать название метода (например, «PUT») - в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.

Получение данных запроса в контроллере

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

извлечение данных из набора объектов контекста;

передача данных в качестве параметров методу действия;

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

В этой статье мы рассмотрим подходы к получению исходных данных для методов действий, концентрируя основное внимание на объектах контекста и параметрах методов действий.

Получение данных из объектов контекста

Когда вы создаете контроллер путем его наследования от базового класса Controller, то получаете в свое распоряжение набор удобных свойств для доступа к информации, касающейся запроса. К таким свойствам относятся Request, Response, RouteData, HttpContext и Server. Каждое перечисленное свойство отвечает за конкретный аспект запроса. Мы называем их удобными свойствами, поскольку каждое из них извлекает определенный тип данных из экземпляра ControllerContext для запроса (который доступен через свойство Controller.ControllerContext).

Наиболее часто используемые объекты контекста и свойства описаны в таблице ниже:

Отдельные свойства, которые здесь упоминались - Request, HttpContext и т.д. - предоставляют объекты контекста. Здесь они подробно не рассматриваются (поскольку являются частью платформы ASP.NET), но следует знать, что такие объекты предоставляют доступ к полезной информации и средствам, и более подробно вы можете прочитать о них в разделе, посвященном ASP.NET Web Forms .

Метод действия может использовать любой из этих объектов контекста для получения информации о запросе, как демонстрируется в примере ниже:

Using System; using System.Web; using System.Web.Mvc; namespace ControllersAndActions.Controllers { public class DerivedController: Controller { public ActionResult Index() { // ... } public ActionResult ActionMethod() { // Получить доступ к разнообразным свойствам из объектов контекста string userName = User.Identity.Name; string serverName = Server.MachineName; string clientIP = Request.UserHostAddress; DateTime dateStamp = HttpContext.Timestamp; // Извлечь отправленные данные из Request.Form string oldProductName = Request.Form["OldName"]; string newProductName = Request.Form["NewName"]; // ... return View(); } } }

Исследовать огромный диапазон доступной информации о контексте запроса можно с помощью средства IntelliSense (в методе действия наберите this. и просмотрите сведения во всплывающем окне) и сети Microsoft Developer Network (просмотрите документацию по классу System.Web.Mvc.Controller и его базовым свойствам или по классу System.Web.Mvc.ControllerContext).

Использование параметров метода действия

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

// ... public ActionResult WeatherForecast() { string city = (string)RouteData.Values["city"]; DateTime forDate = DateTime.Parse(Request.Form["forDate"]); // реализовать прогноз погоды return View(); } // ...

Его можно переписать так, чтобы в нем применялись параметры:

// ... public ActionResult WeatherForecast(string city, DateTime forDate) { // реализовать прогноз погоды return View(); } // ...

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

Полезно отметить, что методы действий не допускают применения параметров out или ref. Их использование не имеет никакого смысла; встретив такой параметр, MVC Framework сгенерирует исключение.

Инфраструктура MVC Framework предоставит значения для параметров метода действия, автоматически проверив объекты контекста и свойства, в том числе Request.QueryString, Request.Form и RouteData.Values. Имена параметров трактуются как нечувствительные к регистру символов, поэтому параметр метода действия по имени city может получить значение, например, из Request.Form["City"].

Создание объектов параметров

Базовый класс Controller получает значения для параметров методов действий с использованием компонентов MVC Framework, называемых поставщиками значений и связывателями моделей . Поставщики значений представляют набор элементов данных, доступных контроллеру. Существуют встроенные поставщики значений, которые производят выборку элементов из Request.Form, Request.QueryString, Request.Files и RouteData.Values. Эти значения затем передаются связывателям моделей, которые пытаются отобразить их на типы параметров, принимаемых методами действий.

Стандартные связыватели моделей могут создавать и заполнять объекты любого типа.NET, включая коллекции и специальные типы, специфичные для проектов. Соответствующий пример приводился в статье Админ панель: редактирование товаров , в котором отправляемая администратором форма была представлена методу действия как одиночный объект Game, несмотря на то, что индивидуальные значения были разбросаны по элементам HTML-формы.

Обязательные и необязательные параметры

Если MVC Framework не может найти значение для параметра ссылочного типа (вроде string или object), метод действия по-прежнему вызывается, но для этого параметра используется значение null. Если не удается найти значение для параметра типа значения (такого как int или double), генерируется исключение и метод действия не вызывается. Сказанное можно интерпретировать и по-другому:

Параметры типа значения являются обязательными. Чтобы сделать их необязательными, необходимо либо задать стандартное значение (как показано в следующем разделе), либо указать для параметра тип, допускающий значения null (наподобие int? или DateTime?); последнее позволит MVC Framework передавать null, если значение не доступно.

Параметры ссылочного типа являются необязательными. Чтобы сделать их обязательными (гарантируя передачу только значений, отличных от null), необходимо добавить в начало метода действия код, отклоняющий значения null. Например, если значение равно null, можно генерировать исключение ArgumentNullException.

Указание стандартных значений для параметров

Если вы хотите обрабатывать запросы, которые не содержат значений для параметров методов действий, но при этом не проверять значения на предмет равенства null и не генерировать исключения в коде, можете воспользоваться средством необязательных параметров языка C#. В примере ниже приведен пример:

// ... public ActionResult WeatherForecast(DateTime forDate, string city = "Москва", int page = 1) { // реализовать прогноз погоды return View(); } // ...

Чтобы пометить параметр как необязательный, необходимо при определении присвоить ему значение. В примере были предоставлены стандартные значения для параметров city и page. Инфраструктура MVC Framework попытается получить значения для этих параметров из запроса, но если окажется, что значения не доступны, будут использоваться стандартные значения.

Для параметра city типа string это означает, что проверка значения на предмет равенства null не понадобится. Если в обрабатываемом запросе значение для city не указано, методу действия для этого параметра будет передана строка "Москва". Что касается параметра типа int, то переживать о возможной ошибке, если значение для page не задано, не придется. Методу действия для этого параметра будет передано стандартное значение, равное 1.

Необязательные параметры могут использоваться для литеральных типов, которые представляют собой типы, определяемые без применения ключевого слова new, в том числе string, int и double.

Если запрос содержит значение для параметра, однако оно не может быть преобразовано к необходимому типу (например, когда пользователь предоставляет нечисловую строку для параметра int), то инфраструктура передает стандартное значение, принятое для данного типа параметра (т.е. 0 для параметра int), и регистрирует указанное в запросе значение как ошибку проверки достоверности в специальном объекте контекста по имени ModelState .

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

Методы GET и POST в HTTP и HTTPS — два самых популярных метода, используемых для передачи данных с клиента на сервер с использованием протокола HTTP (протокол передачи гипертекста). И GET, и POST могут использоваться для отправки запроса и получения ответа, но между ними существует значительная разница.

Разница между запросами GET и POST в HTTP или HTTPS - популярный вопрос на каждом интервью по веб-программированию. Поскольку HTML не зависит от технологии веб-сервера, такой как Java, ASP или PHP и HTTP — это основной протокол в пространстве Интернета, нельзя четко игнорировать важность понимания методов GET и POST. В этой статье мы рассмотрим, что такое HTTP-метод GET, что такое HTTP-метод POST, когда использовать тот или иной запрос и какова разница между ними. Разберем каждое понятие отдельно.

Что такое HTML?

HTML — это язык, используемый для создания веб-страниц. Гипертекст относится к гиперссылкам, которые может содержать HTML-страница. Язык разметки означает способ использования тегов для определения макета страницы и элементов на странице.
Ниже приведен пример HTML, который используется для определения базовой веб-страницы с заголовком и одним абзацем текста:

<Голова>
<Название> TechTerms.com

<Тело>

Это пример абзаца в HTML.

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

За последние несколько десятилетий сеть пережила множество изменений, но HTML всегда был основным языком, используемым для разработки веб-страниц. Интересно, что хотя веб-сайты стали более продвинутыми и интерактивными, HTML стал проще. Если вы сравниваете источник страницы HTML5 с аналогичной страницей, написанной в HTML 4.01 или XHTML 1.0, на странице HTML5 будет меньше кода. Это связано с тем, что современный HTML опирается на каскадные таблицы стилей или JavaScript для форматирования почти всех элементов внутри страницы.

Многие динамические веб-сайты генерируют веб-страницы «на лету», используя серверный язык сценариев, такой как PHP или ASP. Однако даже динамические страницы должны быть отформатированы с использованием HTML. Поэтому языки сценариев часто генерируют HTML-код, который отправляется в веб-браузер.

Протокол передачи гипертекста HTTP предназначен для взаимодействия между клиентами и серверами и работает как протокол запроса-ответа.

Веб-браузер может быть клиентом, а приложение на компьютере, на котором размещен веб-сайт, — сервером.

Клиент (браузер) отправляет HTTP-запрос серверу, сервер возвращает ответ, который содержит информацию о состоянии запроса и может также содержать запрошенный контент.

Два метода запросов GET и POST

Два часто используемых метода для запроса-ответа между клиентом и сервером:

GET - запрашивает данные из указанного ресурса;

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

Перевод GET и POST в буквальном смысле означает получение и постобработку.

Подробнее об HTTP

HTTP — это протокол, используемый для передачи данных через Интернет. Является частью пакета интернет-протокола и определяет команды и службы, используемые для передачи данных веб-страницы.

HTTP использует модель server-client. Клиент может быть домашним компьютером, ноутбуком или мобильным устройством. HTTP-сервер, как правило, является веб-хостом с программным обеспечением веб-сервера, таким как Apache или IIS. Когда пользователь получает доступ к веб-сайту, браузер отправляет запрос на соответствующий веб-сервер и отвечает кодом состояния HTTP. Если URL-адрес действителен и соединение предоставлено, сервер отправит браузеру веб-страницу и связанные файлы.

Общие коды состояния HTTP включают:

200 — успешный запрос (существует веб-страница);

301 — перемещается постоянно (часто перенаправляется на новый URL-адрес);

401 — несанкционированный запрос (требуется авторизация);

500 — внутренняя ошибка сервера (часто вызванная неправильной конфигурацией сервера).

POST и GET в HTTP

HTTP определяет команды GET и POST, которые используются для обработки представлений форм на веб-сайтах. Команда CONNECT используется для облегчения безопасного соединения, которое шифруется с использованием SSL. Зашифрованные HTTP-соединения происходят через HTTPS — расширение HTTP, предназначенное для защищенных передач данных.

URL-адреса, начинающиеся с «http://», доступны по стандартным протоколам передачи гипертекста и по умолчанию используют порт 80. URL-адреса, начинающиеся с «https://», доступны через безопасное соединение HTTPS и часто используют порт 443.

POST

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

Операционные системы устройств Mac и Windows запускают POST каждый раз, когда компьютер загружается или перезапускается. Сканирование проверяет аппаратное обеспечение и гарантирует, что процессор, ОЗУ и устройства хранения данных будут работать правильно. Если во время выполнения POST возникла ошибка, процесс запуска может приостановиться или полностью прекратиться, а на мониторе может появиться сообщение о На ПК ошибки POST часто отображаются на экране информации о BIOS. Они могут выводиться как криптовые коды, такие как «08», или как системное сообщение, например, «Ошибка системной памяти при смещении». На Mac ошибки POST часто обозначаются простой графикой, например, сломанной иконкой папки, которая указывает, что загрузочное устройство не найдено.

Физические проявления

В некоторых случаях экран компьютера может даже не включаться перед ошибками POST. Если это произойдет, коды ошибок могут выводиться через мигающие светодиодные индикаторы или звуковые сигналы. Например, Apple iMac будет воспроизводить три последовательных тона, выдерживать паузу в пять секунд, а затем повторять тоны, когда во время запуска обнаруживается плохая ОЗУ. Большинство ПК также издают звуковые сигналы при обнаружении ошибок POST, хотя каждый производитель использует свои собственные коды.

POST — довольно технический термин, который используют только компьютерные техники на регулярной основе. Однако это хорошая аббревиатура, поскольку помогает лучше понять сообщения об ошибках, которые могут появиться на компьютерах или других электронных устройствах. Если компьютер не запускается из-за ошибки POST, можно использовать другое устройство для поиска значения и причины ошибки с веб-сайта производителя. Затем можно предпринять соответствующие действия — удаление модуля памяти или повторную установку видеокарты с последующим перезапуском оборудования.

GET

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

Значение атрибута name у всех полей на этой форме соответствует названию свойства модели, поэтому система автоматически свяжет значения полей с соответствующими свойствами. А в методе Buy весь этот набор свойств превратится в модель Purchase.

Кроме POST-запросов у нас есть также GET-запросы, при которых все параметры передаются в строке запроса. Например, вторая версия метода Buy в качестве параметра принимает значение типа int: public ActionResult Buy(int id) . Стандартный get-запрос принимает примерно следующую форму: название_ресурса?параметр1=значение1&параметр2=значение2 . То есть запрос к данному методу мог бы выглядеть так: Home/Buy?id=2 . Название параметров метода должно совпадать с названием параметров в строке запроса. Благодаря этому система сможет их автоматически связать. А в самом методе мы сможем получить этот параметр и использовать его по своему усмотрению.

Кроме того, система маршрутизации позволяет создавать маршруты. Например, по умолчанию в проекте MVC определяется следующий маршрут: Контроллер/Метод/id . Последний параметр является опциональным. И благодаря этому мы можем передать параметр id и так: Home/Buy/2

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

Public string Square(int a, int h) { double s = a*h/2.0; return "

В этом случае мы можем обратиться к действию, набрав в адресной строке Home/Square?a=10&h=3 , и приложение выдало бы нам нужный результат.

Мы также можем задать для параметров значения по умолчанию:

Public string Square(int a=10, int h=3) { double s = a*h/2.0; return "

Площадь треугольника с основанием " + a + " и высотой " + h + " равна " + s + "

В этом случае при запросе страницы мы можем указать только один параметр или вообще не указывать(Home/Square?h=5 ).

Получение данных из контекста запроса

Кроме того, мы можем получить параметры, да и не только параметры, но и другие данные, связанные с запросом, из объектов контекста запроса. Нам доступны следующие объекты контекста: Request , Response , RoutedData , HttpContext и Server .

Объект Request содержит коллекцию Params, которая хранит все параметры, переданные в запросы. И мы их можем получить:

Public string Square() { int a = Int32.Parse(Request.Params["a"]); int h = Int32.Parse(Request.Params["h"]); double s = a*h/2.0; return "

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

О формах HTML

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

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

Подробное рассмотрение всех тегов формы HTML выходит за рамки данного раздела. Существует множество источников, рассматривающих создание полезных и удобных форм HTML. Например, с помощью средства просмотра исходного текста страниц используемого обозревателя можно посмотреть, как сделаны формы HTML на других веб-узлах. Кроме того, сведения о передовом использовании форм HTML и других технологий Интернета содержатся на веб-узле Microsoft MSDN Online по адресу http://msdn.microsoft.com/ .

Обработка в ASP сведений, введенных в форму

Когда форма HTML создана, необходимо обработать сведения, введенные пользователем, то есть, отправить их файлу.asp для анализа и других действий. Снова изучите программу HTML, приведенную в предыдущем примере. Заметьте, что атрибут ACTION тега