HTTP GET з тілом запиту

Я розробляю новий RESTful веб-сервіс для нашого додатку.

Роблячи GET для певних організацій, клієнти можуть запитувати вміст об'єкта. Якщо вони хочуть додати деякі параметри (наприклад, сортування списку), вони можуть додати ці параметри в рядок запиту.

Крім того, я хочу, щоб люди могли вказати ці параметри в тілі запиту. Здається, HTTP / 1.1 цього прямо не забороняє. Це дозволить їм вказати більше інформації, а також спростить вказівку складних запитів XML.

Мої запитання:

• Це взагалі гарна ідея?
• Чи будуть у клієнтів HTTP проблеми з використанням органів запиту в GET-запиті?

http://tools.ietf.org/html/rfc2616

Коментар Роя Філдінга щодо включення органу із запитом GET .

Так. Іншими словами, будь-яке повідомлення HTTP-запиту може містити тіло повідомлення, і, таким чином, слід розбирати повідомлення, враховуючи це. Однак семантика сервера для GET обмежена таким чином, що тіло, якщо воно є, не має семантичного значення для запиту. Вимоги до розбору окремо від вимог до семантики методу.

Так, так, ви можете надіслати тіло за допомогою GET, і ні, це ніколи не корисно.

Це частина шаруватого дизайну HTTP / 1.1, який стане зрозумілим знову після розподілу специфікації (робота в процесі роботи).

.... Рой

Так, ви можете надіслати орган запиту за допомогою GET, але він не повинен мати жодного значення. Якщо ви надаєте йому значення, аналізуючи його на сервері та змінюючи свою відповідь на основі її вмісту , ви ігноруєте цю рекомендацію в специфікації HTTP / 1.1, розділ 4.3 :

[...] якщо метод запиту не включає визначену семантику для об'єкта-суті, то тіло повідомлення БУДЕ ігноруватися при обробці запиту.

Опис методу GET у специфікації HTTP / 1.1, розділ 9.3 :

Метод GET означає отримати будь-яку інформацію ([...]), ідентифіковану URI-запитом.

де зазначено, що орган запиту не є частиною ідентифікації ресурсу в GET-запиті, а лише URI запиту.

Оновлення RFC2616, на яке посилається "HTTP / 1.1 специфікація", тепер застаріло. У 2014 році його замінили RFC 7230-7237. Цитата "тіло повідомлення БУДЕ ігноровано під час обробки запиту" було видалено. Тепер просто "Запросити обрамлення повідомлення не залежить від семантики методу, навіть якщо метод не визначає жодного використання для тіла повідомлення". 2-а цитата "Метод GET означає отримати будь-яку інформацію ... ідентифікується Request-URI" було видалено. - З коментаря

Хоча ви можете це зробити, наскільки це явно не виключається специфікацією HTTP, я б запропонував уникнути цього просто тому, що люди не очікують, що речі працюватимуть таким чином. У ланцюжку запитів HTTP існує багато фаз, і хоча вони "в основному" відповідають специфікації HTTP, єдине, в чому ви впевнені, - це те, що вони будуть вести себе як традиційно використовувані веб-браузерами. (Я думаю про такі речі, як прозорі проксі, акселератори, набір інструментів A / V тощо)

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

Однак, якщо у вас є вагомі причини, ідіть до цього.

Ви, мабуть, зіткнетеся з проблемами, якщо коли-небудь спробуєте скористатися кеш-пам’яттю. Проксі-агенти не збираються шукати в GET тілі, щоб перевірити, чи параметри впливають на реакцію.

Ні ресклієнт, ні консоль REST не підтримують це, але curl це робить.

Специфікація HTTP говорить у розділі 4.3

Орган повідомлення НЕ МОЖЕ бути включений у запит, якщо специфікація методу запиту (розділ 5.1.1) не дозволяє надсилати суб'єкт-орган у запитах.

Розділ 5.1.1 переспрямовує нас до розділу 9.x для різних методів. Жоден з них прямо не забороняє включати тіло повідомлення. Однак ...

Розділ 5.2 говорить

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

а в розділі 9.3 сказано

Метод GET означає отримати будь-яку інформацію (у формі сутності), ідентифіковану URI-запитом.

Що в сукупності дозволяє припустити, що при обробці GET-запиту серверу не потрібно перевіряти нічого іншого, крім поля Request-URI та Host заголовка.

Підсумовуючи, специфікація HTTP не заважає вам надсилати тіло повідомлення за допомогою GET, але існує достатня неоднозначність, щоб воно не здивувало мене, якби його підтримували не всі сервери.

Elasticsearch приймає GET запити з тілом. Навіть здається, що це найкращий спосіб: Посібник з еластичних досліджень

Деякі бібліотеки клієнтів (наприклад, драйвер Ruby) можуть записати команду cry на stdout в режимі розробки, і він широко використовує цей синтаксис.

Те, що ви намагаєтеся досягти, вже давно робиться набагато більш поширеним методом, який не покладається на використання корисного навантаження з GET.

Ви можете просто побудувати свій певний медіатип пошуку або, якщо ви хочете бути більш RESTful, використовувати щось на зразок OpenSearch та розмістити запит на URI, який сервер проінструктував, скажіть / пошук. Потім сервер може генерувати результат пошуку або створити остаточний URI і перенаправити за допомогою 303.

Це має перевагу дотримуватися традиційного методу PRG, допомагає кешувати посередникам кешувати результати тощо.

При цьому, URI-коди все одно кодуються для будь-якого, що не є ASCII, і так само є application / x-www-form-urlencoded та multipart / form-data. Я рекомендую використовувати це, а не створювати ще один нестандартний формат json, якщо ваш намір полягає в підтримці сценаріїв ReSTful.

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

Це не є чудовими рішеннями, але надсилання тіла GET може запобігти проблемам для деяких клієнтів - і деяких серверів.

Виконання POST може мати перешкоди з деякими рамками RESTish.

Джуліан Решке запропонував вище використовувати нестандартний HTTP-заголовок на кшталт "ПОШУК", який міг би бути елегантним рішенням, за винятком того, що він ще менше шансів на підтримку.

Перерахувати клієнтів, які можуть і не можуть виконувати кожне з перерахованого вище, може бути найпродуктивнішим.

Клієнти, які не можуть надіслати GET разом із тілом (про який я знаю):

• XmlHTTPRequest Fiddler

Клієнти, які можуть надіслати GET разом із тілом:

• більшість браузерів

Сервери та бібліотеки, які можуть отримати тіло з GET:

• Апач
• PHP

Сервери (та проксі), які знімають тіло з GET:

• ?

Я ставив це питання IGF HTTP WG. Зауваження Роя Філдінга (автора документа http / 1.1 у 1998 році) було таким

"... реалізація буде порушена, щоб зробити що-небудь, крім розбору та відхилення цього органу, якщо воно отримане"

RFC 7213 (HTTPbis) заявляє:

"Корисне навантаження в повідомленні запиту GET не має визначеної семантики;"

Зараз здається зрозумілим, що наміром було те, що семантичне значення в органах запитів GET заборонено, а це означає, що орган запиту не може використовуватися для впливу на результат.

Є проксі-сервери, які точно будуть порушать ваш запит різними способами, якщо ви включите тіло в GET.

Отже, підсумовуючи, не робіть цього.

Який сервер проігнорує його? - fijiaaron 30 серпня 1212 о 21:27

Наприклад, Google робить гірше, ніж ігнорувати його, він вважатиме це помилкою !

Спробуйте самостійно за допомогою простої сітки:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(Вміст 1234 супроводжується CR-LF, тобто загалом 6 байт)

і ви отримаєте:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

Ви також отримуєте 400 поганих запитів від Bing, Apple тощо ..., які обслуговуються AkamaiGhost.

Тому я б не радив використовувати GET-запити з органом.

З RFC 2616, розділ 4.3 , "Тіло повідомлення":

Сервер ДОЛЖЕН прочитати та переслати тіло повідомлення на будь-який запит; якщо метод запиту не включає визначену семантику для сутності-органу, то тіло повідомлення БУДЕ ігноруватися при обробці запиту.

Тобто, сервери повинні завжди читати будь-який наданий орган запиту з мережі (перевіряйте Content-Length або читайте фрагменти тіла тощо). Також довірені особи повинні переслати будь-який такий орган запиту, який вони отримують. Потім, якщо RFC визначає семантику для тіла для даного методу, сервер може фактично використовувати тіло запиту для генерації відповіді. Однак якщо RFC цього не робить визначає семантику для тіла, то сервер повинен ігнорувати його.

Це відповідає цитаті Філдінга вище.

Розділ 9.3 "GET" описує семантику методу GET та не згадує органи запиту. Тому сервер повинен ігнорувати будь-який орган запиту, який він отримує на запит GET.

Згідно з XMLHttpRequest, це недійсно. Зі стандартного :

4.5.6 send()Метод

client . send([body = null])

Ініціює запит. Необов’язковий аргумент надає тіло запиту. Аргумент ігнорується, якщо метод запиту є GETабо HEAD.

Викидає InvalidStateErrorвиняток, якщо будь-який стан не відкрито або встановлено send()прапор.

Метод повинен виконати наступні дії:send(body)

1. Якщо стан не відкрито , киньте InvalidStateErrorвиняток.
2. Якщо send()прапор встановлений, киньте InvalidStateErrorвиняток.
3. Якщо методом запиту є GETабо HEAD, встановіть тіло на нуль.
4. Якщо тіло недійсне, перейдіть до наступного кроку.

Хоча, я не думаю, що це повинно, оскільки GET-запит може потребувати великого вмісту.

Отже, якщо ви покладаєтесь на XMLHttpRequest браузера, швидше за все, це не спрацює.

Якщо ви дійсно хочете відправити кешируваний JSON / XML-тіло у веб-додаток, єдиним розумним місцем для розміщення ваших даних є рядок запиту, закодований з RFC4648: Base 64 Encoding з URL та ім'ям файлу Safe Alphabet . Звичайно, ви можете просто урленкодувати JSON і поставити значення значень парам-адреси URL, але Base64 дає менший результат. Майте на увазі, що існують обмеження щодо розміру URL-адреси, див. Яка максимальна довжина URL-адреси в різних браузерах? .

Ви можете подумати, що =символ прокладки Base64 може бути поганим для значення парам-адреси URL, однак, здається, це не так - див. Цю дискусію: http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html . Однак ви не повинні ставити кодовані дані без імені парама, тому що кодована рядок із накладкою буде інтерпретуватися як парам-ключ із порожнім значенням. Я б використав щось подібне ?_b64=<encodeddata>.

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

А як щодо кодованих заголовків невідповідних base64? "SOMETHINGAPP-PARAMS: sdfSD45fdg45 / aS"

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

Я засмучений тим, що REST як протокол не підтримує OOP, а Getметод є доказом. Як рішення, ви можете серіалізувати свій DTO до JSON, а потім створити рядок запиту. На стороні сервера ви зможете дезаріалізувати рядок запиту до DTO.

Погляньте на:

• Дизайн на основі повідомлень у ServiceStack
• Створення RESTful веб-сервісів на основі повідомлень з WCF

Підхід на основі повідомлень може допомогти вам вирішити обмеження методу Get. Ви зможете надіслати будь-який DTO, як з органом запиту

Рамка веб-служб Nelibur надає функціональні можливості, якими ви можете користуватися

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Наприклад, він працює з Curl, Apache та PHP.

Файл PHP:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Команда консолі:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

Вихід:

GET
{"the": "body"}

IMHO, ви можете просто надіслати JSONзакодований (тобто. encodeURIComponent) В URL, таким чином, ви не порушите HTTPспецифікації і не потрапите JSONна сервер.

У вас є список варіантів, які набагато кращі, ніж використання тіла запиту з GET.

Дозвольте «припустимо, що у вас є категорії та елементи для кожної категорії. Обидва повинні бути ідентифіковані id ("catid" / "itemid" заради цього прикладу). Ви хочете сортувати за іншим параметром "sortby" у визначеному "порядку". Ви хочете передати параметри для "sortby" та "order":

Ти можеш:

1. Використовуйте рядки запитів, наприклад example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. Використовуйте mod_rewrite (або подібний) для шляхів: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. Використовуйте окремі заголовки HTTP, які ви передаєте разом із запитом
4. Використовуйте інший метод, наприклад POST, для отримання ресурсу.

Усі мають свої мінуси, але набагато краще, ніж використання GET з тілом.

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

Багато проміжних інфраструктур можуть просто відхиляти такі запити.

Наприклад, забудьте про використання деяких з доступних CDN в передній частині вашого веб - сайту, як цей один :

Якщо GETзапит глядача включає тіло, CloudFront повертає глядачеві код статусу HTTP 403 (Заборонено).

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

Я використовую програму RestTemplate Spring Framework у своїй програмі клієнта, і на стороні сервера я визначив GET-запит з тілом Json. Моє основне призначення те саме, що і ваше: коли запит має численні параметри, розміщення їх у тілі здається акуратнішим, ніж введення їх у тривалий рядок URI. Так?

Але, на жаль, це не працює! Сторона сервера кинула таке виняток:

org.springframework.http.converter.HttpMessageNotReadableException: обов'язковий орган запиту відсутній ...

Але я впевнений, що тіло повідомлень правильно надано моїм клієнтським кодом, і що не так?

Я простежив метод RestTemplate.exchange () і виявив наступне:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

Зауважте, що у методі ExecuteInternal () вхідний аргумент 'bufferedOutput' містить тіло повідомлення, надане моїм кодом. Я бачив це через налагоджувач.

Однак, завдяки PripravConnection (), getDoOutput () у ExecuteInternal () завжди повертає помилку, що, у свою чергу, робить забуференний вихід повністю ігнорований! Він не скопійований у вихідний потік.

Отже, моя серверна програма не отримала жодного тіла повідомлення і кинула це виняток.

Це приклад про RestTemplate рамки Весна. Справа в тому, що навіть якщо тіло повідомлення більше не заборонено специфікацією HTTP, деякі бібліотеки клієнта або сервера або рамки все ще можуть відповідати старій специфікації і відхиляти тіло повідомлення з GET-запиту.