Разоблачение RESTful конечных точек для одного до многих отношений

Question

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

• Колледжем имеет много Факультетов
• факультета принадлежат колледжа

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

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

• Создайте новый факультет в этом колледже этой ферме. Один из возможных способов сделать это в двух операциях.
  • POST /faculties/
  • PUT /college/1/faculties
• Удалить факультет из этого колледжа. Снова две операции
  • GET /college/1/faculties: Список связанных факультетов. Каждый из них будет содержать собственный URL-адрес, например /faculties/1.
  • DELETE /college/1/faculties/1: URL-адрес выглядит лучше, но как разоблачить этот URL-адрес?
• Добавить один или несколько факультетов в этом колледже.
  • PUT /college/1/faculties, который принимает полный список факультетов этого колледжа.
• Удалите этот конкретный сектор целиком.
  • DELETE /sectors/1: Выглядит хорошо, но необходимо позаботиться о кеше /faculties/1/sectors.

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

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

• Факультеты имеет много Факультеты
• Департамент имеет много лабораторий так далее.

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

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

Answer 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 - Bulk Create or Update in single request и How to Update a REST Resource Collection. Такой подход позволяет создавать элементы в одном вызове и затем присоединять их. Он позволяет собирать обработку на элементах.

Надежда Я ясно, и это поможет вам, Тьерри

Answer 2

Использование:

• POST: для создания новых записей.
• PUT: редактировать существующие записи.
• УДАЛИТЬ: удалить существующие записи.
• GET: для получения одного или списка записей.

Это стандартные методы, используемые для сохранения сохраненных данных.

И не смешивать сущность с адресами конечных точек. Относитесь к каждому объекту в конечных точках, как если бы между ними не было никакой связи. И всегда в единственном числе, конечная точка заканчивается faculty, а не faculties.

POST /college/ 
POST /faculty/ 
POST /department/ 
POST /lab/ 

Если вам необходимо дифференцировать возвращение списка записей из одной записи, всегда возвращает список записей с помощью GET и возвращает одну запись, используя GET с параметром ID. Тот же метод и та же конечная точка могут использоваться для извлечения обоих (список и одиночная запись). Нет необходимости создавать разные конечные точки для извлечения списков и отдельных записей.