У чому потреба таких методів, як GET та POST у протоколі HTTP?

Чи не можемо ми реалізувати протокол HTTP, використовуючи лише орган запиту та орган відповіді?

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

Чому протокол HTTP має поняття про методи?

З відповідей я розумію, чому поняття методів існує. Це призводить до іншого пов'язаного питання:

Наприклад, в gmail compose link буде надісланий запит PUT / POST та дані. Як браузер дізнається, який метод використовувати? Чи містить надіслана сервером сторінка gmail, що містить ім'я методу, який слід використовувати при виклику gmail compose request? коли ми зателефонуємо на 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-адреса. Що ти врятував? Пара байтів про те, щоб не сказати GET? Трохи більше про викидання цих примхливих заголовків .. Сервер також врятував деякі - але що робити, якщо ви не можете розробити те, що вам надіслав? Що робити, якщо ви запитали URL-адресу, яка закінчилася в JPEG, і вона надіслала вам кілька байтів, які створюють зображення, але це в PNG? Неповний PNG при цьому. Якби у нас був заголовок, який говорив, скільки байтів йдещоб надіслати, тоді ми б знали, чи отримана нами кількість байтів - це цілий файл чи ні. Що робити, якщо сервер отримав відповідь, щоб зберегти пропускну здатність, але не сказав вам? Ви збираєтеся витратити значну обчислювальну потужність, намагаючись розробити те, що воно надіслало.

Врешті-решт нам потрібна метформація - інформація про інформацію; нам потрібні заголовки; нам потрібні файли, щоб вони мали імена, розширення, створені дати. Нам потрібні люди, які мають дні народження, щоб сказати, будь ласка, і подякуйте і т. Д. - світ переповнений протоколами і інформацією про контекст, тому нам не доведеться весь час сідати і працювати все з нуля. Це коштує трохи місця для зберігання, але це легко того варто

Чи реально потрібна реалізація різних методів HTTP?

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

Цілком може статися так, що жоден з ваших користувачів ніколи не видасть нічого, окрім GET-запиту, не використовуватиме стійкі з'єднання, не надсилатиме нічого іншого, крім JSON, як основний текст або не повинен приймати що-небудь, крім тексту / прості, щоб ви могли написати справді впорядкований веб-сервер, який відповідає лише дуже обмеженим вимогам клієнтського браузера. Але ви не могли просто довільно вирішити усунути основні правила, які роблять "деякий текст, передаючи сокет", що таке 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 за замовчуванням, convention / spec, тому що це постанова відбудеться під час введення URL-адреси та натискання return

Чи містить надіслана сервером сторінка gmail, що містить ім'я методу, який слід використовувати при виклику gmail compose request?

Це одна з ключових речей, на яку я натякаю у коментарях вище. У сучасній павутині навіть не про сторінки. Як тільки сторінки були файлами на диску, браузер отримає. Потім вони стали сторінками, які динамічно генерувались динамічно шляхом розміщення даних у шаблон. Але це все ще включало в себе "запит на нову сторінку з сервера, отримання сторінки, показ сторінки". Переміщення сторінок стало дуже гладким; ви не бачили, як вони завантажують і змінюють розмір і тузають їх макет навколо, щоб він виглядав плавніше, але все одно браузер замінював одну цілу сторінку або частину сторінки іншою

Сучасний спосіб роботи - це додаток на одній сторінці; у браузері є документ в пам'яті, який певним чином відображається, сценарій викликів до thebservr і повертає якийсь саморіз інформації, а також маніпулює документом, щоб частина сторінки візуально змінювалася, щоб відображати нову інформацію - усі речі працюють без браузер колись завантажує ще одну нову сторінку; це просто перетворитись на інтерфейс користувача, де його частини оновлюються так само, як і типовий клієнтський додаток, наприклад, слово чи прогноз. Нові елементи з’являються поверх інших елементів і їх можна перетягнути навколо імітації діалогових вікон тощо. Все це - браузер сценарію, який надсилає запити, використовуючи будь-який метод 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 може розглядатися як один конкретний випадок загальних принципів віддаленого виклику процедур: ви повідомляєте серверу, що ви хочете, з якимсь змінним полем у запиті, сервер відповідає відповідно. На сьогоднішній день, завдяки складній інтерактивності веб-версії 2.0, ці самі функції відображаються у кожному полі запиту: URL-адресі, заголовках, тілі, а кожен додаток і програма розуміє їх по-своєму. Однак спочатку Інтернет був простішим, використовували статичні сторінки, і вважалося, що методи HTTP передбачають достатній рівень інтерактивності. Зокрема, HTTP має безліч методів, які застосовуються рідко, якщо взагалі колись, коли деякі з них бачать світло лише завдяки REST. Напр. PUT і DELETE були переможеними перед REST, а TRACE і PATCH є afaik досі невидимими. Це означає, що модель RPC HTTP не зробила

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

Зауважте також, що методи HTTP мають присвоєну їм семантику, яку шанують браузери та проміжне програмне забезпечення, як проксі-сервери: запити POST, PUT, DELETE та PATCH можуть мати побічні ефекти і, ймовірно, не бути ідентичними, тому додатки та програмне забезпечення на стороні клієнта обережно не запускати ці запити без явних дій від користувача. На практиці, погано розроблені веб-додатки використовували GET для незахищених дій, наприклад, попередній переглядач веб-акселераторів Google спричинив проблеми, видаливши купу даних на таких сайтах , тому його бета-версія була призупинена незабаром після запуску.

Отже, щоб відповісти на питання "чи можемо ми": звичайно, вам просто потрібно узгодити протокол, який підкаже серверній програмі, яку дію ви хочете виконати, а потім ви помістите аргументи десь у 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 або створює динамічний вміст такого роду.

Методи запиту - це базовий стандартизований набір дієслів про те, що робити з цими файлами ...

• GET означає завантаження
• HEAD означає отримати інформацію про
• PUT означає завантаження
• УДАЛИТИ означає видалити
• POST означає надсилання даних у
• ВАРІАНТИ означає, скажіть мені, що я міг би зробити

У день HTTP / 0.9 рядок запиту - це єдине, що знаходиться в частині запиту протоколу; немає заголовків запитів, немає заголовків відповідей. Ви просто введіть GET /somefileі натисніть Enter, сервер поверне тіло відповіді (тобто HTML-вміст), і все добре, спасибі до побачення (тобто закрийте з'єднання).

Якщо ви хотіли просто запитати, чому це було розроблено саме так ? Моя відповідь полягає в тому, що вона спочатку була написана для обробки того типу обміну вмістом, який існував тоді , тобто, що подає статичні HTML-файли за бажанням користувачів.

Однак якщо ви хотіли запитати про те, як поводитися з цією семантикою на сучасному сервері додатків ...

Чи не можемо ми реалізувати протокол HTTP, використовуючи лише тіло запиту та орган відповіді?

Чи реально потрібна реалізація різних методів HTTP?

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

Якщо ви йдете проти очікувань, не ретельно розглядаючи їх наслідки , трапляться різні неприємні речі, як-от ...

• Коли ви використовуєте метод передачі даних для використання даних, сервер може виплюнути помилку 414 " URI Too Long ".
• Коли ви застосовуєте метод GET для використання для зміни даних, ви виявите, що модифікація іноді не проходить, коли користувач стоїть за проксі-сервером кешування, або якщо несподівані зміни відбудуться, коли користувач відкликає URL-адресу із закладок (або коли веб-сканери доходять до неї) .
• Якщо ви неправильно реагуєте на метод HEAD, ви виявите, що ваші автоматичні інструменти перевірки веб-сайту (наприклад wget --spider) порушують ваш сайт.
• Під час завантаження вмісту POST для завантаження контенту ви побачите, що закладки або навіть введення URL-адреси у браузер не працюватимуть.
• І багато іншого...

" Новачок знає правила, але ветерани знають винятки. ".

У будь-якому випадку, ви можете знайти якісь поважні виправдання, щоб суперечити деяким правилам для деяких випадків вузького використання; але обов’язково зробіть своє дослідження та врахуйте всі можливості. В іншому випадку, ви закінчите, щоб досягти сумісної сумісності та зруйнувати "досвід користувачів".

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

Недбале порушення стандарту також означає, що ви застосовуєте дискримінацію щодо своїх користувачів.

В теорії це правда, що ми могли б отримати всюди, і це могло б працювати. Деяке програмне забезпечення навіть використовує GET з тілом запиту (я дивлюсь на вас, еластичний пошук / кібану). Звичайно, це жахливо.

Найважливіша причина тому, що різні методи мають різну семантику. Деякі в безпеці, деякі - безсилі. Деякі - і те, і інше. Подивіться, які є

Це важливо, наприклад, під час взаємодії з іншими програмами. Кінцеві точки 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-адресу, яка дозволяє їм вводити шкідливий код або дані на ваш сервер.