Получение объектов со связанными объектами с использованием REST API - PullRequest
Новая
       19

Получение объектов со связанными объектами с использованием REST API

1 голос
/ 07 июля 2011

мы используем REST API для связи между нашим клиентом (UI) и сервером. Мы реализовали постраничную GET-тинг ресурсов одного типа, например: 

GET http://../cars?page-size=10,start-index=3

вернет вам максимум 10 автомобилей, начиная с автомобиля 21 (т.е. 3-я страница из 10 автомобилей).

Мы хотим добавить возможность возвращать сущности со связанными сущностями, в которых может быть много связанных сущностей (возможно, десятки или сотни) одной основной сущности. В настоящее время это выполняется с помощью 2 запросов: например, сначала GET для автомобилей, затем GET для дверей с использованием ранее выбранных идентификаторов автомобилей в качестве параметра: 

GET http://../doors?car-ids=1,2,5,7,...

Однако, чтобы минимизировать количество запросов, мы хотели бы использовать 1 запрос для возврата необходимой информации. Возникают следующие вопросы:

  1. Как пейджинг должен быть интегрирован с такой функциональностью? Должно ли количество связанных объектов (дверей) быть ограничено размером страницы основного объекта (автомобиля)? Может быть, нам следует разделить размер страницы основного объекта и связанных объектов (например, 10 автомобилей, максимум 2 двери для каждого автомобиля)?
  2. Как мы можем обеспечить масштабируемость решения на стороне сервера с точки зрения использования памяти? В настоящее время мы используем JAXB для сериализации объектов в XML. Должны ли мы рассмотреть возможность использования потоковых методов XML (STAX) для предотвращения загрузки всех объектов в память?

Большое спасибо.

Ответы [ 2 ]

1 голос
/ 07 июля 2011

Я думаю, что проблема REST здесь менее важна, чем анализ ОО

Ресурс здесь - Автомобиль.Количество дверей является атрибутом, поэтому смоделируйте вашу систему вокруг ресурса Car с помощью разумного способа выразить ваши запросы.

Наименее неожиданный (и, следовательно, вероятно, лучший) подход заключается в добавлении к существующему запросу автомобилей.,Возьмем ваш пример:

GET http: //../cars? Doors = 2 +, размер страницы = 10, начальный индекс = 3

Помните, что ключевым аспектом REST является то, что у каждого ресурса есть URL.REST ничего не говорит о том, как формируется URL, поэтому не беспокойтесь о вложенных ресурсах в стиле RAIL. По словам самого Филдинга ...

Важно то, что у каждого важного ресурса есть URI.разрешение представления этого ресурса с помощью GET.

1 голос
/ 07 июля 2011

По вопросу 1:

Я бы создал ресурс моментального снимка, который возвращает сам объект ресурса, а также все связанные объекты: GET /car/{car-id}/snapshot Зная, что это вернет моментальный снимок с возможно большим объектом ответа, можно вернуть довольно большой, не разбитый на страницы список элементов (то есть, дверей). Однако вы можете ограничить число запросов, которые клиенты могут отправлять на этот довольно дорогой ресурс моментального снимка. Вы даже можете предоставить ресурс для пакетных запросов, например /cars/snapshots, где вы можете POST несколько идентификаторов автомобилей и получать несколько снимков одновременно (в этом случае я бы ограничил количество идентификаторов, которые будут включены в пакет) запрос также).

С другой стороны, я создаю нумерованный список с подразделами: GET /car/{car-id}/doors (от 303 до первой страницы) и GET /car/{car-id}/door/{door-id as cursor} для каждой страницы.

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

...