Моделирование более сложного отношения сущностей в RESTful пути (ящики и узлы)

Вот пример, чтобы задать мой вопрос. У меня есть модель, которая содержит "ящики", и у них есть конечная точка REST:

/boxes /boxes/{boxId}

Эта модель также содержит "узлы":

/nodes /nodes/{nodeId}

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

быстрый визуальный пример ящиков и узлов

Я пытаюсь определить, как моделировать это в неудивительном, RESTful пути. Я вижу пару способов сделать это. Но я не уверен, что я должен использовать:

  • Модель /borders как полнофункциональный тип сущности с его собственной конечной точкой. В блоках указаны четыре границы (сверху, снизу, слева, справа). Имеют границы, ссылающиеся на список узлов. У узлов ссылаться на список границ.

  • Модель /boxNodeRelationships со своей конечной точкой и каждая из этих отношений указывает на поле, node и содержит поле "граница" (перечисление с четырьмя параметрами).

Оба являются похожими, а скорее "тяжелыми" для их целей. Альтернатива должна быть немного более ad-hoc:

  1. Отображает список объектов { border, node }. Дайте узлам список объектов { box, border }. Эти объекты будут возвращены из вызовов GET и ожидаются от вызовов POST/PUT, но не будут полностью полноценными типами с конечной точкой.

Я хотел бы знать, как RESTifarian решит это, а также услышит некоторые плюсы и минусы этих подходов. Я также хотел бы знать, существуют ли другие подходы, принципиально иные.

Ответы

Ответ 1

Я бы создал 3 объекта:

  • Коробка
  • Border
  • Node

И отношения:

  • Коробка может иметь n границ.
  • Граница может иметь n узлов

Итак, вы можете обратиться к ним:

Чтобы получить первый node: /boxes/1/borders/1/nodes/1

У вас может быть некоторая логика:

if /boxes/1/borders contain /nodes/1 and /boxes/2/borders contain /borders/1 then they intersect

И так далее.