Что здесь не так?
<a href="posts/http-is-your-wrench/delete">Delete article</a>
Я думаю, что вы можете ответить за 5 секунд. GET-запросы, подобно тем, которые генерируются гиперссылками, должны быть идемпотентными (математическое слово, означающее, что их выполнение от 1 до N раз не меняет конечный результат). Оно не должно изменять любой ресурс, присутствующий на сервере.
Метод POST (и другие методы, которые обычно не поддерживаются браузерами без перегруженного POST), можно использовать для модификации ресурсов. Таким образом, обычно кнопки удаления более популярны, чем ссылки удаления, и они отправляют запрос POST, сгенерированный их элементом <form>.
Зачем следовать этому подходу? Потому что это в семантике стандарта HTTP: теоретически за ссылкой « Удалить статью» может следовать сканер или другой автоматический механизм (в конце концов, он идемпотентен, считал сканер при удалении всего в базе данных.) Или его результат может быть неправильно кешируется , хотя нет смысла удалять пост в блоге или пользователя более одного раза.
Что здесь не так?
<documentrequest>
<language>en</language>
<query>original http specification</query>
</documentrequest>
В этом XML-запросе мы используем надстройку для наших метаданных (язык, на котором мы хотим записать ответ), в то время как HTTP уже предоставляет стандартные заголовки, такие как Accept-Language для определения этой информации.
Этот SOAP-подобный запрос является одним из простых примеров изобретения квадратного колеса вместо того, чтобы использовать уже определенный для нас стандарт двадцатилетней давности, принятый любым компьютером на планете (попробуйте найти операционную систему, распространяемую без браузера).
Это только два примера. HTTP является не только очень популярным стандартом, но и примером распределенной системы, которая действительно хорошо работает. Если вы сравните его с Java Rmi , чья ложная прозрачность и тайм-ауты могут привести к сбоям внешнего интерфейса , он будет чрезвычайно надежным. То же самое касается сравнения с другими механизмами удаленного вызова процедур.
Если вы хотите построить распределенную систему в 2011 году, у вас есть пример великолепного примера: большая интероперабельная система, называемая World Wide Web , где машины с различными операционными системами взаимодействуют без сбоев, без необходимости использования пользовательских клиентов. ,
Если вы здесь, я думаю, вы такой же веб-разработчик, как и я. Если вы предоставляете HTML-страницы для жизни (или пишете код, который делает это за вас, надеюсь), у вас нет никаких оправданий в том, что вы не знаете основ протокола HTTP, из которого выйдет любая часть вашей работы, которую сможет увидеть пользователь.
Что читать
Спецификация HTTP 1.1 (RFC 2616), вероятно, является ключевым документом, который нужно прочитать раз в жизни. Он действительно полный, так как по определению является стандартом. Тем не менее, это очень абстрактно, чтобы обеспечить вневременность, я думаю. Он был написан в 1999 году для обновления стандарта 1990 года.
Это также скучно во многих разделах, поскольку в нем описываются не только концепции HTTP, но также физические форматы запросов и ответов и спецификации низкого уровня, которые вы никогда не сможете использовать, если не напишите HTTP-клиент.
ОСТАЛЬНЫЕ
Так, где мы можем найти более современный материал об использовании HTTP? А может быть, сравнение с другими стилями, такими как RPC и SOAP, которых не было на момент написания спецификации HTTP?
Ответ содержится в материале REST . REST (Передача репрезентативного состояния) — это архитектурный стиль, который предлагает децентрализованную веб-модель, которая будет использоваться для связи машин, а не только людей. Современные общедоступные веб-сервисы написаны почти только в стиле REST.
Возможно, вам никогда не придется писать веб-сервис, но некоторые знания REST определенно помогут вам в разработке URL-адресов вашего приложения, методов доступа к ним, заголовков для отправки и так далее.
Архитектурные стили и проектирование сетевых программных архитектур , широко известных как доктор философии Роя Филдинга. Тезис представляет официальную презентацию REST, особенно в ее главе 5. Рой Филдинг является одним из авторов спецификации HTTP, так что на самом деле это тот же источник.
RESTful Web Services — это полная книга, опубликованная в 2007 году, которая научит вас, как соответствовать REST в клиентах и серверах веб-служб. В нем есть несколько проницательных примеров того, как REST — это не только сдвиг в использовании HTTP в лучшем виде , но и представление ресурсов (идентифицируемых Urls), а не методов для вызова, что было бы типично для RPC. Например, сброс пароля в REST можно рассматривать не как действие для вызова, а как / user / 42 / password-reset для создания с PUT или с POST на / user / 42 .
Вывод
Мы не пишем веб-сервисы каждый день, но, скорее всего, страницы, действия, представления и контроллеры. Тем не менее, HTTP является зонтиком, который охватывает все эти сущности, и для нас это то же самое, что ножницы для электриков и ключи для сантехников. Изучение концепций HTTP гораздо важнее, чем новые возможности вашей платформы JavaScript.