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

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

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

/users/44/timeslots/

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

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

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

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

Ответ 1

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

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

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

Как только это может быть ограничено идеями/концепциями, как указано выше. Вы фильтруете больше, добавляя запросы /users/ 44/timeslots? Day = weekdays & dow = mon

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

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

Ответ 2

timeslots - ресурс коллекции, почему бы вам просто не включить разбиение на страницы этого ресурса

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

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

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

Ответ 3

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

Надеюсь, что это поможет.

Ответ 4

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

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