Что делать с огромными ресурсами в REST API

Question

Я подключаю интерфейс REST к существующему приложению, и мне любопытно, какое наиболее подходящее решение заключается в работе с ресурсами, которые возвращали бы непомерный объем данных, если бы их нужно было извлечь.

Приложение представляет собой существующую систему расписаний, а один из ресурсов представляет собой набор пользовательских «временных интервалов».Пример URI для этих ресурсов:

/users/44/timeslots/

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

Я хочу знать, как (или если) мне следует иметь дело с ситуацией, когда выдача GET по указанному выше URI вернула бы мегабайты данных из десятков или сотен тысяч строк и заняла бы достаточное количество сервераресурс на самом деле ответить в первую очередь.

• Есть ли ответ HTTP, который используется соглашением в этих ситуациях?
  Я нашел код HTTP 413, который относится к объекту запроса, который является слишком большим, но нетот, который был бы уместен, когда сущность Response была бы слишком большой
• Существует ли альтернативное соглашение об ограничении ответа или сообщении клиенту, что это глупый запрос?
• Должен ли я просто позволить серверу выполнить этот массовый запрос?

РЕДАКТИРОВАТЬ: Чтобы было ясно, у меня реализована фильтрация и разбиение ресурсаи рассмотрел нумерацию страниц других крупных коллекционных ресурсов.Я хочу соответствующим образом отвечать на запросы, которые не имеют смысла (и, очевидно, были запрошены клиентом, создающим URI).

Answer 1

Вы можете создавать свои URI так, как хотите, для кодирования любой концепции .

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

/users/44/timeslots/afternoon
/users/44/timeslots/offshift
/users/44/timeslots/hours/1
/users/44/timeslots/hours/1
/users/44/timeslots/UTC1624

Однажды можно также ограничиться идеями / концепциями, как указано выше. Вы фильтруете больше, добавляя запросы / пользователи / 44 / временные интервалы? День = дни недели & день = пн

Использование или концепция и фильтры, подобные этому, естественно ограничат размер ответа. Но вам нужно попробовать разработать свой API , а не входить в эту ситуацию . Если ваш клиент плохо себя ведет, отправьте ему 400 Bad Request . Если что-то идет не так на вашей стороне сервера, используйте код 5XX.

Воспользуйтесь одним из инструментов REST - Гипермедиа и ссылки (См. Также HATEOAS ) Ссылка на следующую часть вашей гипермедиа, используйте «чанкоподобные концепции» что ваш домен понимает (страницы, временные интервалы). Нет необходимости загружать мегабайты, которые также не годятся для кэширования , что влияет на масштабируемость / скорость.

Answer 2

временных интервалов - это ресурс для сбора, почему бы просто не включить нумерацию страниц на этом ресурсе

см. Здесь: Разбиение на страницы в веб-приложении REST

вызов get для коллекции без информации о странице просто возвращает первую страницу (с размером страницы по умолчанию)

Должен ли я просто позволить серверу выполнить этот массивный запрос? Я думаю, что вы не должны, но решать вам, может ли сервер обрабатывать большие объемы? Вы находите это действительным вариантом использования?

Answer 3

Вы можете использовать пользовательский заголовок Range - см. http://otac0n.com/blog/2012/11/21/range-header-i-choose-you.html

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

Answer 4

Это может быть слишком слабый ответ, но вот как моя команда справилась с этим.Такие большие ресурсы необходимы для предоставления дополнительной информации о фильтрации.Если информация о фильтрации отсутствует для сохранения размера в определенном диапазоне, мы возвращаем Внутреннюю ошибку (500) с соответствующим сообщением, указывающим на то, что произошел сбой при правильном использовании RESTful API.помогает.