LINUX.ORG.RU

Курим REST: коллекция в коллекции

 ,


0

5

Положим, есть ресурс, одним из полей которого является коллекция ID подчинённого ресурса.

Пусть это будут Автолюбитель и Мойшыно:

Автолюбитель = { id: 1, name: 'Билл Гейтс', cars: [1, 2, 3, 5] }

Мойшыно = { id: 1, make: 'Toyota', number: 'x 958 xxx' }

Как организовать доступ к такой подчинённой коллекции? Клиент получает объект Автолюбитель и должен, получается, знать, что поле cars представляет собой массив id машин, что нехорошо с точки зрения decoupling (?).

Если же сделать отдельный URL для получения подчинённой коллекции, вроде /owner/1/cars, получается, что в объекте Автолюбитель это поле cars ни в винду, ни в Красную Армию, и его надо игнорировать и серверу, и клиенту.

Надо делать исходя из задач. Иногда удобней хранить машины в отдельной коллекции, иногда нет смысла отрывать машины от хозяина. Рассматривай это как будто ты хранишь сразу собранные из нормализированой базы данные, в структуру которую тебе нужно описать по предметной области а не придумать под загоном «ПО ВСЕМ ПРАВИЛАМ». а лучше используй в этом месте dbal (сойдет и самопал из 1 функции), в любой момент сменишь эту схему, если на практике она себя не оправдает. Все надо тестировать, преждевременные оптимизации зло, кудах кудах, ну ты в курсе.

trashymichael ★★★
()

я бы не делал отдельную ручку для получения машин, почему бы в users/1 просто не показать какие у него машины? тебе все равно не нужны будут машины без юзера и юзер без машин. хотя это смотря что ты будешь делать с машинами, но map-reduce тебя тут выручат, на первое время так уж точно

я часто грешу такими-себе супер-документами с кучей полей от разных контекстов, просто так удобнее, а для отбрасывания лишнего сходится любой фильтер. например, в schematics есть некие роли, которые на самом деле фильтры, грубо говоря я делаю User(user).to_primitive('public') или to_primitive('private'), — сериализирую наружу только нужные в контексте поля

trashymichael ★★★
()
Ответ на: комментарий от trashymichael

сами роли описываются примитивно через

class Model:
   ...
   class Options:
      public = whitelist('id', 'first_name')
      private = blacklist('balance', 'cars')

короче говоря это обычный pick/omit фильтр

trashymichael ★★★
()
Ответ на: комментарий от trashymichael

Ага, понятно. Я всё пытаюсь придумать способ и с сервера (mongo) передавать практически готовые выборки, не перестраивая структуру, и удобно, без говнокода их отображать на клиенте, в браузере. Пока не очень успешно. Видимо, чем-то надо жертвовать. Что будет правильнее - на сервере перелопачивать объекты? То есть - выбранный объект

{ id: 1, cars: [1, 2, 3] }
превращаем в
{ id: 1, cars: [ { id:1, ... }, { id: 2, ...} ] }
и только потом отдаём клиенту.

Отдаваемый cars может даже содержать объекты с одними айдишниками, главное, чтобы это были объекты, тогда на клиенте достаточно просто организовать ленивую выборку и пополнение объектов свойствами. С примитивными же типами такое не прокатит.

discordia
() автор топика
Ответ на: комментарий от discordia

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

trashymichael ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.