Лучшая практика REST для слишком долгого URIs
У меня есть сервисы REST, которые должны получить действительно долгие запросы через, ДОБИРАЮТСЯ. Скажите, например, что я хочу запросить сервис со многими географическими координатами, чтобы узнать, что что-то обо всем этом координирует.
1) Моя первая мысль состояла в том, чтобы использовать длинный URIs и увеличить макс. длину URI контейнера сервлета.
Это было бы похоже на это:
GET http://some.test/myresource?query={really big JSON object}
Но кажется, что дольше, чем 2 КБ URIs не надежны из-за старых прокси-серверов (который является правильным?).
2) Мое обходное решение должно создать временный ресурс по почте сначала и использовать URI этого ресурса, поскольку параметр в фактическом ПОЛУЧАЕТ запрос. Это было бы похоже на это:
POST http://some.test/temp
Request Body: {really big JSON object}
201 Created Location: http://some.test/temp/12309871
GET http://some.test/myresource?query=http://some.test/temp/12309871
3) Используйте тело, ПОЛУЧАЮТ запрос. Я прочитал ответы на вопрос, является ли это хорошей идеей использовать тело ПОЛУЧИТЬ запроса на запрос, и согласие: нет. Даже Roy Fielding говорит, что это - плохая идея.
4) Другой подход мог быть должен интерпретировать POST, поскольку "создают ресурс результата запроса" и удаляют этот ресурс после запроса. Но я полагаю что быть не УСПОКОИТЕЛЬНЫМ и быть плохой идеей.
Существует ли лучший способ обработать большие запросы с, ПОЛУЧАЮТ запросы?
5 ответов
Я думал, что весь момент в покое заключалось в том, чтобы работать над «документами» (или что-то одинаково). УРИ ЧАСТЬ ЗАПРОСА - это уникально определить ресурс для работы. Часть тела в отличие от того, что «содержимое» часть документа.
Следовательно, используйте «тело» часть запроса.
также обратите внимание, что семантика запроса «GET» не должна использоваться для «наведения» или «размещения» документов (комментарий относительно вашего примера «запроса» выше, который, похоже, «создает» объект) Отказ
В любом случае, как вы уже указывали, часть URI ограничена (по которой я уверен, что я уверен).
Если вы обеспокоены кэшированием, то использование ETAG / последних модифицированных полей (в сочетании с «условным получением» помогает этой цели помогает этой цели.
Разве вы не можете просто отправить большие данные JSON с помощью корпуса запроса Get, вместо создания ресурса TEMP?
Несмотря на то, что он не на 100% кошер, я обнаружил, что он хорошо работает с Firefox, а IE и IMO, криастрофю, представляет собой нищеэлегантную и обычно предоставляет детали реализации, которые не относятся к URI. Просто обязательно добавьте параметр QueryString Cache Buster, если вам нужны актуальные данные, потому что сервер будет игнорировать данные при определении того, может ли он вернуть кэшированный ответ.
См. здесь для обсуждения плюсов и минусов начинкой данных в телу запроса получения.
Если вы используете запрос на получение, чтобы отправить большие объекты, вы не используете отдых правильно.
- Получение должно быть использовано для извлечения Ресурсы (через какой-то уникальный Идентификатор)
- Пост следует использовать для Создание ресурсов (с содержанием в организме)
- PUT следует использовать для Обновление ресурса (с Содержимое в теле)
- Удалить следует использовать для удаления ресурса
, если вы будете следовать этим рекомендациям, вам никогда не придется иметь чрезмерно длинные УРИ.
Некоторые рекомендации по отдыху лучших практики здесь: http://www.xml.com/pub/a/2004/08/11/rest.html
Вот небольшое различие по второму варианту. Создайте себе процессорный ресурс под названием QueryMaker. Отобразите в нем свои параметры и позвольте ему перенаправить вас на ресурс временного запроса, который вернет вам результаты.
POST /QueryMaker
Body: Big Json representation of parameters
303: See Other
Location: http://example.org/TemporaryQueries/123213
Самым большим ограничением длины URL в открытом Интернете является IE, который ограничивает их до 2083 символов.
Некоторые прокси (например, все, кроме последних версий Squid) ограничивают их примерно 4k, хотя это медленно движется к 8k.
Ваш обходной путь #2 - хороший подход, в зависимости от вашего случая использования.
Отправка тел на GET может быть разрешена некоторыми реализациями и запрещена другими, так что это плохая идея как по причинам совместимости, так и по теоретическим причинам. Самое главное, как кэш узнает, что использовать в качестве ключа?