Дилемма сортировки RESTful API
У меня есть REST API, реализованный по принципу, что rest просто возвращает основные документы и ссылки в этих документах, как получить другие вещи и т.д. и т.п.
Например, /car/5 даст мне model:blabla , user_id: 1, а затем, если вам нужен владелец, вы получите /user/1, чтобы получить данные пользователя...
Таким образом, в БД можно избежать JOINS и прочего... все вещи связываются между собой, а данные взаимосвязаны на клиентской части - все просто, легко кэшировать, уменьшать кэш, масштабировать и т.д.
Но что произойдет, когда вам понадобится сортировка?
Представьте, что у нас есть некоторое представление на фронтенде для отображения следующих данных: Модель автомобиля, Имя пользователя и т.д... и вы хотите отсортировать, например, по имени пользователя.
Вы не можете сказать /car/5 сортировать по имени пользователя, потому что он знает только идентификаторы пользователей...
Один из вариантов, который я вижу, это сортировка по пользователю /user/list?sortby=username и последующее определение, какие из этих возвращенных идентификаторов действительно относятся к автомобилю. но это означает, что нам нужно получить ВСЕХ пользователей... и использовать только часть из них, что кажется убийственно узким местом в производительности.
Спасибо за любые подсказки
3 ответа
Я думаю, вы пытаетесь избежать присоединения по совершенно неправильным причинам, так как при таком подходе вам придется обслуживать намного больше запросов.
Если вместо этого вы вернете всю информацию, которую вы показываете (то есть на стороне базы данных объединений), то клиентам придется делать меньше запросов, и вы можете выполнять сортировку без необходимость (ленивой) загрузки всех дочерних объектов.
Другой вариант - вернуть дочерние объекты как дочерние элементы XML (аналогично тому, как работает интерфейс RESTful OpenStreetMap). У вас все еще есть одно обращение от клиента, и вы сможете оптимизировать запросы, чтобы минимизировать нагрузку на БД.
Если вы избегаете всех соединений на сервере и покидаете его до клиента, тогда в этом случае вы также должны оставить сортировку клиенту. Это связано с тем, что для сортировки автомобилей по имени пользователя необходимо выполнить соединение.
Вы можете создать другой ресурс под названием CarsAndOwners или аналогичный, который возвращает объединенный список, после чего становится разумным выполнить сортировку на сервере.
Я бы начал с представления идеального RESTful запроса, который я хотел бы написать, например:
/car/list?sortby=username
А затем выяснил, как его реализовать.
Теперь ваш метод list дает вам car объекты, которые не раскрывают username, как вы сказали, но я не думаю, что это имеет значение. Вся сортировка должна происходить на сервере до подготовки списка.
Чтобы сделать это, вам придется в какой-то момент присоединить ваши объекты car к объектам user, и нет никакого способа уклониться от этой проблемы. Единственный выбор, который у вас есть, - это то, где вы это делаете.
Если вы работаете с традиционной RDBMS, то имеет смысл делать это на уровне БД.
Используете ли вы слой ORM между API вашего приложения и базой данных?