Предоставление конечных точек RESTful для отношений «один ко многим»

Рассмотрим следующую связь между двумя ресурсами

  • В колледже много факультетов
  • Преподаватель относится к колледжу

Очевидно, что факультет здесь не является первоклассным ресурсом.

Теперь мне нужны конечные точки для следующих операций.

  • Create a new faculty in this college this farm. One possible way to do this in two operations.
    • POST /faculties/
    • PUT /college/1/faculties
  • Remove a faculty from this college. Again two operations
    • GET /college/1/faculties: List of associated faculties. Each will contain a self url like /faculties/1.
    • DELETE /college/1/faculties/1: URL выглядит лучше, но как показать этот URL?
  • Add one or more faculties under that college.
    • PUT /college/1/faculties that accepts a complete list of faculties of this college.
  • Delete that particular sector entirely.
    • DELETE /sectors/1: Looks good but needs to take care of the cache of /faculties/1/sectors.

Что было бы лучше в этом случае? Я читал об открытии ресурсов членства, но при таком подходе, если в колледже 10 факультетов, потребуется 10 отдельных http-вызовов, чтобы получить все из членства.

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

  • Факультет имеет много кафедр
  • В отделе много лабораторий и так далее.

Кроме того, в архитектуре RESTful клиент никогда не должен заполнять URL-адреса.

Любое предложение?


person Samiron    schedule 24.03.2015    source источник
comment
Кроме того, я думаю, вы должны быть последовательны в использовании множественного числа - вы используете единственное число для колледжа, множественное число для факультетов и секторов. Лично я всегда использую единственное число, потому что мне нравится, чтобы путь соответствовал имени ресурса. Неважно, что вы выберете, но будьте последовательны.   -  person justAnotherUser    schedule 24.03.2015


Ответы (1)


В прошлом я писал пост о том, как OData реализует такие аспекты (функция «свойства навигации»). См. эту ссылку: https://templth.wordpress.com/2014/12/08/updating-data-links-of-odata-v4-services-with-olingo/.

Эта другая ссылка также может дать вам несколько интересных советов, поскольку в конце она описывает URL-адреса и соответствующие полезные данные: http://www.asp.net/web-api/overview/odata-support-in-aspnet.-web-api/odata-v4/entity-relations-in-odata-v4.

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

Я бы увидел следующие возможные запросы на множественную кардинальность (колледж -> факультеты):

  • POST /faculties/: добавить факультет, не привязанный к колледжу
  • POST /college/1/faculties: прикрепить факультет к колледжу и в конечном итоге создать его, если он не существует (на основе отправленного контента)
  • DELETE /college/1/faculties/?ref=/faculties/1 отделить факультет от колледжа

Что-то, что вы могли бы также рассмотреть, это поместить ссылку на колледж в факультете (запрос POST /faculties). Таким образом, вы можете прикрепить элемент во время его создания.

В противном случае это PUT /college/1/faculties направлено на замену всего представления, то есть всех факультетов, прикрепленных к конкретному колледжу.

Вы также можете использовать метод POST или PATCH, чтобы минимизировать количество запросов. Вы можете просмотреть эти ответы для получения более подробной информации: «>REST API — массовое создание или обновление в одном запросе и Как обновить коллекцию ресурсов REST. Такой подход позволяет создавать элементы за один вызов, а затем присоединять их. Это позволяет собирать обработку по элементам.

Надеюсь, я был понятен, и это поможет вам, Тьерри.

person Thierry Templier    schedule 24.03.2015