Что делать с огромными ресурсами в 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-адресам (представляющие разделы или страницы или иным образом отфильтрованные версии исходного ресурса).