Зачем нужны такие методы, как GET и POST в протоколе HTTP?

Разве мы не можем реализовать протокол HTTP, используя только тело запроса и тело ответа?

Например, URL будет содержать запрос, который будет отображаться на функцию в зависимости от языка программирования на стороне сервера, скажем, сервлета, и в ответ будет отправлен ответ HTML и JavaScript.

Почему протокол HTTP имеет понятие методов?

Из ответов я получаю некоторое представление о том, почему существует понятие методов. Это приводит к другому связанному вопросу:

Например, в gmail compose link будут отправлены запрос PUT / POST и данные. Как браузер узнает, какой метод использовать? Включает ли страница gmail, отправляемая сервером, имя метода, используемого при вызове gmail, составляет запрос? когда мы вызываем www.gmail.com, он должен использовать метод GET, как браузер узнает, что этот метод использовать?

PS : У меня недостаточно кредитов, чтобы комментировать ответы, поэтому я не могу комментировать многие вопросы, поднятые людьми, связанные с намерением, стоящим за этим вопросом.

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

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

Зачем нужны такие методы, как GET и POST в протоколе HTTP?

Они, наряду с некоторыми другими вещами, такими как форматы заголовков, правила разделения заголовков и тел, составляют основу протокола HTTP.

Разве мы не можем реализовать протокол HTTP, используя только тело запроса и тело ответа?

Нет, потому что тогда все, что вы создали, не будет протоколом HTTP

Например, URL будет содержать запрос, который будет отображаться на функцию в зависимости от языка программирования на стороне сервера, скажем, сервлета, и в ответ будет отправлен ответ HTML и JavaScript.

Поздравляю, вы только что изобрели новый протокол! Теперь, если вы хотите создать стандартную организацию для управления и поддержки, разработки и т. Д., Он может обогнать HTTP однажды

Я ценю, что это немного ненормально, но нет ничего волшебного в Интернете, TCP / IP или связи между серверами и клиентами. Вы открываете соединение и отправляете несколько слов по проводам, образуя разговор. Разговор действительно должен придерживаться некоторой утвержденной спецификации на обоих концах, если запросы должны быть поняты и разумные ответы доставлены. Это ничем не отличается от любого диалога в мире. Вы говорите по-английски, ваш сосед говорит по-китайски. Надеюсь, что ваших махов, указаний и дрожания кулака будет достаточно, чтобы передать ваше сообщение о том, что вы не хотите, чтобы он парковал свою машину перед вашим домом.

Вернитесь в Интернет, если вы откроете сокет для веб-сервера, совместимого с HTTP, и отправите следующее:

EHLO
AUTH LOGIN

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

Вот почему вы не можете реализовать протокол HTTP без реализации протокола HTTP; если то, что вы пишете, не соответствует протоколу, то это просто не протокол - это что-то другое, и оно не будет работать так, как указано в протоколе

Если мы поработаем с вашим примером на мгновение; где клиент подключается и просто сообщает что-то, похожее на URL-адрес .. И сервер понимает это и просто отправляет что-то, похожее на HTML / JS (веб-страницу), тогда, конечно, это может сработать. Что ты сохранил, хотя? Пару байтов, не говоря GET? Еще немного о том, чтобы избавиться от этих надоедливых заголовков. Сервер тоже кое-что сохранил - но что, если вы не можете понять, что он вам послал? Что делать, если вы запросили URL-адрес, оканчивающийся на JPEG, и он отправил вам несколько байтов, которые составляют изображение, но оно в формате PNG? Неполный PNG в этом. Если бы у нас был заголовок, в котором говорилось, сколько это было байтов собираетсячтобы отправить, тогда мы бы знали, было ли количество байтов, которые мы получили, на самом деле весь файл или нет. Что, если сервер сжал ответ, чтобы сэкономить пропускную способность, но не сказал вам? Вы собираетесь потратить значительные вычислительные мощности, пытаясь понять, что он послал.

В конце концов, нам нужна метаинформация - информация об информации; нам нужны заголовки; нам нужны файлы с именами, расширениями, датами создания. Нам нужны люди, чтобы у нас были дни рождения, чтобы сказать «пожалуйста», «спасибо» и т. Д. - мир полон протоколов и битов информации о контексте, поэтому нам не нужно все время работать с нуля. Это стоит немного места для хранения, но оно того стоит

Реализация различных методов HTTP действительно необходима?

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

Вполне может случиться так, что ни один из ваших пользователей никогда не выдаст ничего, кроме запроса GET, не будет использовать постоянные соединения, отправлять что-либо, кроме JSON в качестве основного текста, или будет нуждаться в принятии чего-либо, кроме text / plain, чтобы вы могли написать действительно урезанный веб-сервер, который отвечает только очень ограниченным требованиям клиентского браузера. Но вы не могли просто произвольно решить покончить с основными правилами, которые делают «некоторый текст, передаваемый по сокету», что такое HTTP; Вы не можете отказаться от базового представления о том, что запрос будет выглядеть следующим образом:

VERB URL VERSION
header: value

maybe_body

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

Обновить

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

Почему протокол HTTP имеет понятие методов?

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

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

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

На стороне клиента появились сценарии, плагины и расширения для браузера, и все они были нацелены на то, чтобы превратить браузер в мощный инструмент всего. На стороне сервера активная генерация контента на основе алгоритмов или данных базы данных была большим толчком, и она продолжает развиваться до такой степени, что на диске, вероятно, больше нет файлов - конечно, мы сохраняем файл изображения или сценария в виде файла на веб-сервер и браузер ПОЛУЧИТЕ его, но все чаще изображения, которые показывает браузер, и скрипты, которые он запускает, - это не файлы, которые вы можете открыть в проводнике, это генерируемый контент, который является результатом некоторого процесса компиляции, выполняемого по требованию , SVG, который описывает, как рисовать пиксели, а не растровый массив пикселей, или JavaScript, созданный из сценариев более высокого уровня, таких как TypeScript

При создании современных мульти-мегабайтных страниц, вероятно, только часть из них теперь является фиксированным содержимым на диске; Данные базы данных отформатированы и преобразованы в html, который будет использовать браузер, и это делается сервером в ответ на несколько различных программных программ, на которые ссылается каким-либо образом URL

Я упомянул в комментариях к вопросу, что это немного похоже на полный круг. В те времена, когда компьютеры стоили сотни тысяч заполненных комнат, было обычным делом разрешать нескольким пользователям использовать один сверхмощный центральный мэйнфрейм с помощью сотен тупых терминалов - клавиатуры и мыши, зеленого экрана, отправлять текст, получать некоторые текст Со временем, когда вычислительная мощность возросла, а цены упали, люди стали в конечном итоге иметь настольные компьютеры, более мощные, чем ранние мэйнфреймы, и возможность локально запускать мощные приложения, поэтому модель мэйнфреймов устарела. Однако он никогда не исчезал, потому что вещи просто эволюционировали, чтобы перейти в другую сторону и несколько вернуться к центральному серверу, обеспечивающему большую часть полезных функций приложения, и сотне клиентских компьютеров, которые делают очень мало, кроме рисования на экране, и отправлять и получать данные на / с сервера. Этот промежуточный период, когда ваш компьютер был достаточно умен, чтобы одновременно запускать собственную копию слова и мировоззрения, снова уступил место онлайн-офису, где ваш браузер - это устройство для рисования изображений на экране и редактирования документа / электронной почты, которую вы получаете ». Вы пишете как то, что живет на сервере, сохраняется там, отправляется и передается другим пользователям, как представление о том, что браузер - это просто оболочка, которая обеспечивает частичное представление в любой момент этой вещи, которая живет в другом месте.

Из ответов я получаю некоторое представление о том, почему существует понятие методов. Это приводит к другому связанному вопросу:

Например, в gmail compose link будут отправлены запрос PUT / POST и данные. Как браузер узнает, какой метод использовать?

Он использует GET по умолчанию, по соглашению / спецификации, так как это то, что указывается, должно произойти, когда вы набираете URL и нажимаете return

Включает ли страница gmail, отправляемая сервером, имя метода, используемого при вызове gmail, составляет запрос?

Это одна из ключевых вещей, на которые я намекаю в комментариях выше. В современном Интернете речь идет даже не о страницах. Когда страницы были файлами на диске, браузер получал их. Затем они стали страницами, которые в основном создавались динамически путем размещения данных в шаблоне. Но он все еще включал процесс «запросить новую страницу с сервера, получить страницу, показать страницу». Обмен страниц стал действительно гладким; вы не видели, как они загружали, изменяли размеры и дергали свой макет, чтобы он выглядел более плавным, но браузер по-прежнему заменял одну целую страницу или часть страницы другой

Современный способ сделать это с помощью одностраничного приложения; в браузере есть документ, который отображается в памяти определенным образом, он вызывает сценарии, обращаясь к thebservr, и возвращает некоторый кусок информации обратно, а также манипулирует документом, так что часть страницы изменяется визуально, отображая новую информацию - все работает без браузер всегда загружает другую новую страницу; это просто стало пользовательским интерфейсом, где его части обновляются как обычное клиентское приложение, такое как word или outlook. Новые элементы появляются поверх других элементов и могут перетаскиваться вокруг имитирующих диалоговых окон и т. Д. Все это - механизм сценариев браузера, отправляющий запросы с использованием любого http-метода, который хочет разработчик, получающий данные обратно и выскакивающий из документа, который рисует браузер. Вы можете представить, что современный браузер - это блестящее устройство, похожее на целую операционную систему или виртуальный компьютер; программируемое устройство, которое имеет довольно стандартизированный способ рисования объектов на экране, воспроизведения звука, захвата пользовательского ввода и отправки его на обработку. Все, что вам нужно сделать, чтобы нарисовать ваш пользовательский интерфейс, это предоставить ему html / css, который делает пользовательский интерфейс, а затем постоянно настраивать html, чтобы браузер изменил то, что рисует. Черт, люди так привыкли видеть изменение адресной строки / использовать ее как направление намерений, что одностраничное приложение будет программно изменять URL-адрес, даже если не выполняется навигация (запрашивающая новые страницы) Все, что вам нужно сделать, чтобы нарисовать ваш пользовательский интерфейс, это предоставить ему html / css, который делает пользовательский интерфейс, а затем постоянно настраивать html, чтобы браузер изменил то, что рисует. Черт, люди так привыкли видеть изменение адресной строки / использовать ее как направление намерений, что одностраничное приложение будет программно изменять URL-адрес, даже если не выполняется навигация (запрашивающая новые страницы) Все, что вам нужно сделать, чтобы нарисовать ваш пользовательский интерфейс, это предоставить ему html / css, который делает пользовательский интерфейс, а затем постоянно настраивать html, чтобы браузер изменил то, что рисует. Черт, люди так привыкли видеть изменение адресной строки / использовать ее как направление намерений, что одностраничное приложение будет программно изменять URL-адрес, даже если не выполняется навигация (запрашивающая новые страницы)

когда мы вызываем www.gmail.com, он должен использовать метод GET, как браузер узнает, что этот метод использовать?

Правда. Потому что это указано. Первый запрос, как это исторически всегда было - ПОЛУЧИТЕ какой-то начальный html, чтобы нарисовать пользовательский интерфейс, затем либо ткните и манипулируйте им навсегда, либо получите другую страницу с другим скриптом, который тыкает, манипулирует и создает отзывчивый реактивный пользовательский интерфейс.

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

История. Наследие. Мы можем теоретически отказаться от всех методов http завтра - мы на уровне сложности программирования, где методы устарели, поскольку URL-адреса могут обрабатываться до такой степени, что они могут быть механизмом переключения, который указывает серверу, что вы хотите сохранить данные в тело как черновик электронной почты, или удалите черновик - на сервере нет файла / emails / draft / save / 1234 - сервер запрограммирован так, чтобы разделить этот URL и знать, что делать с данными тела - сохранить это как черновик письма под id 1234

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

HTTP можно рассматривать как один конкретный случай общих принципов удаленного вызова процедур: вы сообщаете серверу, что вы хотите, с помощью некоторого переменного поля в запросе, сервер отвечает соответствующим образом. В настоящее время из-за сложной интерактивности «Web 2.0» эти же функции добавляются в каждое поле запроса: URL, заголовки, тело - и каждый сервер приложений и приложение понимают их по-своему. Однако изначально сеть была проще, использовались статические страницы, и считалось, что методы HTTP обеспечивают достаточный уровень интерактивности. Примечательно, что HTTP имеет множество методов, которые используются редко, если вообще когда-либо, причем некоторые из них видят свет только благодаря REST. Например, PUT и DELETE были убиты до REST, а TRACE и PATCH еще не видны. Вывод заключается в том, что HTTP-модель RPC не

REST сделал прямо противоположное тому, что вы предлагаете, отметив, что методы HTTP обслуживают типичные сценарии использования CRUD большинства приложений, если возвращаются PUT и DELETE.

Также обратите внимание, что для методов HTTP назначена семантика, которая учитывается браузерами и промежуточным программным обеспечением, таким как прокси-серверы: запросы POST, PUT, DELETE и PATCH могут иметь побочные эффекты и, вероятно, не быть идемпотентными, поэтому клиентские приложения и промежуточное ПО проявляют осторожность. не запускать эти запросы без явных действий со стороны пользователя. На практике плохо разработанные веб-приложения использовали GET для небезопасных действий, и, например, средство предварительной выборки Google Web Accelerator вызывало проблемы, удаляя кучу данных на таких сайтах , поэтому его бета-версия была приостановлена ​​вскоре после запуска.

Итак, чтобы ответить на вопрос «можем ли мы»: конечно, вам просто нужно согласовать протокол, который сообщит серверному приложению, какое действие вы хотите выполнить, а затем вы поместите аргументы где-то в URL / теле - например, целевой элемент для действия. Набор действий ограничен только определенными приложениями, поэтому вам нужен расширяемый протокол. Но вам нужно будет сообщить клиентским приложениям, какие запросы безопасны, и, возможно, принять во внимание другие нюансы, такие как контроль кэша.

С моей личной точки зрения разработчика, это может значительно облегчить создание конечных точек API. Например, если я пишу контроллер, который управляет продуктами на веб-сайте, я могу использовать один и тот же URL-адрес для выполнения нескольких различных операций.

Примеры:

GET https://example.com/api/products/1234

Это принесет детали продукта 1234.

POST https://example.com/api/products/1234

Это создаст продукт с идентификатором 1234, используя данные в теле запроса.

PUT https://example.com/api/products/1234

Это обновит продукт 1234 с данными в теле запроса.

DELETE https://example.com/api/products/1234

Это удалит продукт с идентификатором 1234.

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

Зачем нужны такие методы, как GET и POST в протоколе HTTP?

Кажется, вы забыли старые времена, когда HTTP-серверы существовали только для обслуживания файлов. ; не работает скрипт, CGI или создает динамический контент такого рода.

Эти методы запроса являются основным стандартизированным набором глаголов на том , что делать с этими файлами ...

• ПОЛУЧИТЬ означает скачать
• ГОЛОВА означает получить информацию о
• PUT означает загрузку
• УДАЛИТЬ означает удалить
• POST означает отправку данных в
• ВАРИАНТЫ означает, скажите мне, что я мог сделать

В день HTTP / 0.9, строка запрос является единственной в запросе ноге протокола; нет заголовка запроса, нет заголовка ответа. Вы просто набираете , нажимаете , сервер возвращает тело ответа (то есть содержимое HTML), и все в порядке, пока (то есть закрытие соединения).GET /somefileEnter

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

Однако, если вы хотели спросить о том, как обрабатывать эту семантику в современном сервере приложений ...

Разве мы не можем реализовать протокол HTTP, используя только тело запроса и тело ответа?

Реализация различных методов HTTP действительно необходима?

Мой ответ: делайте все, что вы хотели бы сделать, но имейте в виду, что вы не должны реализовывать логику приложения таким образом, который не соответствует ожиданиям протокола : ожидания, такие как GET, не должны изменять данные (или очень слабо, иметь по крайней мере идемпотентный результат). ), HEAD должен иметь тот же результат, что и GET, но без тела ответа, PUT должен сделать доступным содержимое целевого URI (если оно выполнено).

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

• Когда вы вводите метод GET в отправку данных, сервер может выплеснуть ошибку 414 « URI Too Long » в вашем лице.
• Когда вы используете метод GET для использования при модификации данных, вы обнаружите, что модификация иногда не проходит, когда пользователь находится за кэширующим прокси-сервером, или происходят непредвиденные изменения, когда пользователь вспоминает URL из закладки (или когда веб-сканеры достигают его) ,
• Если вы неправильно ответите на метод HEAD, вы обнаружите, что ваши инструменты автоматической проверки сайта (например wget --spider) заблокированы на вашем сайте.
• Когда вы загрузите метод POST в загрузку контента, вы обнаружите, что закладки или даже ввод URL-адреса в браузере не будут работать.
• И многое другое ...

« Новичок знает правила, но ветераны знают исключения ».

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

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

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

В теории это правда, что мы могли бы использовать «повсюду», и это бы работало. Некоторые программы даже используют GET с телом запроса (я смотрю на васasticsearch / kibana). Это, конечно, ужасная вещь.

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

Это важно, например, при взаимодействии с другими приложениями. GET конечные точки не должны иметь побочных эффектов. Это важно, когда Google сканирует вашу сторону. Предполагается, что PUT является идемпотентом, что означает, что клиент может повторить попытку в случае сбоя. Это не относится к POST, поэтому браузеры должны иметь некрасивое поле подтверждения, если вы нажмете f5 в запросе на публикацию.

Посмотрите, что может произойти, если вы используете GET, где вы должны были использовать POST

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

GET_MyVar() не принимает входной параметр (он же тело запроса), но что-то возвращает.

POST_MyVar(string blah)что-то делает с вводом (опять же, тело запроса) и может что-то вернуть. (Также необходимо как минимум вернуть код ответа, чтобы мы знали, что функция запущена !!)

DELETE_MyVar() Также, вероятно, ничего не берет и ожидается что-то удалить.

Да, мы могли бы реализовать все это с помощью:
MyVar(string Action, string? blah)

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

Но одно из преимуществ этого подхода заключается в том, что он позволяет браузерам и серверам оптимизировать работу этих вещей. Например, возможно, сервер захочет заблокировать все запросы, где Action==DELETE. Может быть, браузеры хотят кэшировать вещи, гдеAction==GET. если нет, в каждой функции мы должны написатьif (Action==Delete) {return AngryFace}

Не требуется реализовывать все точно в соответствии с протоколом, но протокол - это, по сути, набор правил, которым мы все решили следовать. Таким образом, я могу легко угадать, что будет делать ваш сайт, даже если я не видел сервер!

Методы HTTP служат разным целям. В общем, GETдля загрузки и POSTдля загрузки.

Единственный способ реализовать часть протокола HTTP с использованием только тела запроса и тела ответа - реализовать POST. GETне имеет тела запроса. У него есть только запрос с заголовками, но нет тела. Это просто запрос на скачивание документа. POSTимеет как тело запроса (загрузка файла), так и тело ответа (документ, показывающий результат).

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

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

В любом случае, нет веской причины для создания веб-сервера для вашего сайта с нуля. Протокол HTTP сложен. В дополнение к различным методам вам также потребуется реализовать конвейерную обработку и группированные запросы. Гораздо проще построить ваше веб-приложение поверх веб-сервера, такого как Apache, Nginx или IIS, который обрабатывает протокол HTTP для вас. Вы упоминаете сервлеты, поэтому, возможно, вам следует использовать веб-серверы Tomcat или JBoss, которые запускают сервлеты.

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

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

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